sbom_snapshot has no margin against its 120s timeout on the self-hosted pool
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start with tests/meson.build:1621 and scripts/ci/check-sbom-snapshot.sh:54, then trace where WIRELOG_SBOM_REQUIRED=1 is set and which runner legs execute the gate. Compare the logged timings and runner assignments described here. Done means the gate runs or skips deterministically, its timeout is justified by measured timings, and the sanitizer timing gap and required-variable behavior are explained.
Written by the indexing model from the issue text.
Description
tests/meson.build:1621 gives sbom_snapshot a 120 s meson timeout. On the
self-hosted pool that budget has no usable margin, so the gate's outcome is
decided by host load rather than by the diff under test.
Measured
sbom_snapshot outcome and wall time, by leg, from job logs:
| run | head | leg | result | time | runner |
|---|---|---|---|---|---|
| 36522559220 | 9f2b9475 |
Sanitizers ubuntu-latest gcc | TIMEOUT | 120.17s | semantic-reasoning-i401-6 |
| 36522559220 | 9f2b9475 |
Sanitizers ubuntu-latest clang | TIMEOUT | 120.12s | semantic-reasoning-i401-6-2 |
| 36518853483 | bc32c162 |
Sanitizers ubuntu-latest gcc | OK | 117.83s | self-hosted |
| 36518511800 | 7c714a1b |
Sanitizers ubuntu-latest clang | OK | 98.42s | self-hosted |
| 36518511800 | 7c714a1b |
Sanitizers ubuntu-latest gcc | OK | 35.02s | self-hosted |
| 36518853483 | bc32c162 |
Sanitizers ubuntu-latest clang | OK | 20.75s | self-hosted |
| 36406725961 | c3415221 |
Sanitizers ubuntu-latest clang | OK | 3.54s | self-hosted |
| 36519324533 | 0696455b |
Sanitizers ubuntu-latest gcc | OK | 3.01s | self-hosted |
| 36525150045 | 84a4d3ce |
Build ubuntu-latest clang | OK | 5.34s | semantic-reasoning-i401-6-2 |
Identical work spans 3.01 s to 120.17 s, a 40x range. One passing leg
cleared the budget by 2.17 s. Locally the same gate takes 5.56 s in the
full suite.
The two TIMEOUT legs ran concurrently, 04:47:55Z-05:22:13Z. Their runner
names share an i401-6 prefix, which suggests two slots on one host; the
overlap is certain from the timestamps even if the co-location is inferred
from naming.
The budget is not what #1917 left it
#1917 excluded the meson build root from the scan, on the premise that
reading it spent the budget. Measured locally against a 1.7 GB
-Db_sanitize=address,undefined build tree, three runs each:
with exclusion: 2514ms 2515ms 2462ms
without exclusion: 4993ms 4944ms 5070ms
The exclusion halves the cost but does not stop the traversal, and neither
figure is near 120 s. The gap between 2.5 s of work and a 120 s timeout is
filled by contention on the shared host, not by the scan itself.
Why this matters beyond a flaky red
ubuntu-latest answers from two pools and only the self-hosted one ships
syft, which scripts/ci/check-sbom-snapshot.sh:54 already records. The gate
therefore runs or SKIPs by runner assignment. Across the last four CI Main
runs, 16 of 17 ubuntu-latest legs SKIPped at ~0.01 s; exactly one enforced
(84a4d3ce, Build / ubuntu-latest / clang, self-hosted, OK 5.34 s). A green
CI Main is therefore weak evidence that this gate passed: usually it did not
run at all.
Suggested acceptance
- The gate runs deterministically on a named leg, or SKIPs deterministically,
rather than by runner assignment. - Its timeout is derived from a measured distribution, and no leg both runs
and finishes within a few percent of the timeout. - The ~20x gap between a Build leg and a Sanitizers leg on the same runner
slot (5.34 s vs 120.12 s) is explained before the number is raised, so a
bump does not mask real growth in the dependency surface. - State where
WIRELOG_SBOM_REQUIRED=1is set and whether pool-dependence
defeats it.
Related: #1917 (build-tree exclusion, closed), #1581 (runner placement
variance, open).
Found while reviewing #2023, whose two red sanitizer legs are this timeout
with Fail: 0 / Ok: 403. That PR changes no C source, script, or SBOM
baseline, and meson timeouts are per-test, so it cannot influence this gate.
- Dominant language
- C
- Stars
- 18
- Forks
- 2
- Avg merge
- 10h 5m
- Merged PRs (30d)
- 146
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from semantic-reasoning/wirelog
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
semantic-reasoning/wirelog#2229 ·
Maintainers usually reply within 1 day
-
Doc: insert executor and incremental consolidation leave sorted runs, not globally sorted headsOpen
Difficulty 1/5 Under an hour Newbie friendliness 83/100
semantic-reasoning/wirelog#2133 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
semantic-reasoning/wirelog#2042 ·
Maintainers usually reply within 1 day
-
p2-medium
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
semantic-reasoning/wirelog#1914 ·
Maintainers usually reply within 1 day
-
Refused evaluations still abort or corrupt the retried model when no completion cursor is armedOpen
Difficulty 4/5 3-5 days Newbie friendliness 48/100
semantic-reasoning/wirelog#2348 ·
Maintainers usually reply within 1 day
All issues in semantic-reasoning/wirelog
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
micropython/micropython#19906 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 10 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sk3llo/ffmpeg_kit_flutter#176 ·