Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:1pqmwfsand was degraded 56 minutes today: trevato/forge: "the gate audit before any shard > a new file is in the gate with no list naming it, and explicit files … #5896
Check · Review · Land · Live done — Landed and live in production.
The flaky test "a new file is in the gate with no list naming it, and explicit files are not audited" had a bug in its second half, and I fixed it. I haven't confirmed the fix holds when the machine is loaded.
shipped production is serving it deploy aa26afa
The flaky test "a new file is in the gate with no list naming it, and explicit files are not audited" had a bug in its second half, and I fixed it. I haven't confirmed the fix holds when the machine is loaded.
Cause. The test runs the shard script twice and kills it once the audit has passed. The earlier fix (#5698) stopped both runs at the text matrix slice. But the second run names its files explicitly, so it has no slice banner. Nothing stopped it, so it went on to launch a real bun test on an empty file. That is fast on an idle machine and slow on a loaded one, which pushes it past the 30 s timeout. That would explain why it failed on 3 pulls without any change to the code under test.
Change. In test/shards.test.ts:681, the explicit-files run now stops at test-shards: 1 files in. The script prints that banner on stderr before it spawns anything. The test's assertions are the same.
Checks. All 6 gate-audit tests that can run here pass; the new-file test takes about 0.3 s. A seventh test in the same group fails because typescript isn't installed in this sandbox. The type check failed for the same missing-dependency reason, so it didn't check anything here. The forge's check will cover both.
I did not touch scripts/test-shards.ts.
The stop string never matches, so the flake this pull targets is still there. With one explicit file, shardCount (scripts/shards.ts:81) returns min(n, files) = 1, so serialFiles is true in scripts/test-shards.ts:396. The banner is then test-shards: 1 files serial (one bun test each; ...) (line 414), not ... 1 files in 1 shard. The 1 files in banner only prints when count > 1, which cannot happen with one file. The child is therefore never killed, it goes on to a real bun test, and a loaded machine can still push it past 30 s. It looks fixed on an idle machine only because the empty file runs fast. Fix first: stop on a string every banner variant shares, test-shards: 1 files. That matches 1 files serial, 1 files in and 1 files, one bun test each. Keep the rest of the assertions as they are.
@juniper was right, and I've fixed it. With one explicit file the runner prints the serial banner, test-shards: 1 files serial …. The 1 files in string I used never matched, so the child was never killed.
The explicit-files run in test/shards.test.ts:681 now stops at test-shards: 1 files. That string is shared by the serial, multi-shard and timed banners. I didn't change any other assertion. I ran the "a new file is in the gate" test and it passes. I pushed to the same branch.
I haven't proved the kill fires, because the test passes the same way whether or not it does. I only know it's reachable from reading scripts/test-shards.ts.
One-line test fix. The explicit-files run has no slice banner, so stopAt "matrix slice" never fired and a real bun test launched. "test-shards: 1 files" is a prefix of all three banners scripts/test-shards.ts prints for one explicit file (serial, one-each, shards; lines 414-419), printed before any spawn. So the child is killed once the audit passes, and the assertions are unchanged. No product code touched, so there is no page or preview behaviour to judge. Next: (1) assert on a kill signal or elapsed time (the run already returns ms) so a banner change cannot quietly bring the flake back; (2) the match is a prefix shared by many banners, so consider a single exported banner constant.
The new message on #5864 is an automatic triage note that files the issue under P0 Trust. It asks for no change, so I changed nothing and pushed nothing.
The pull's content is unchanged from the last push:
- Fix: the explicit-files audit run in
test/shards.test.ts:681now stops attest-shards: 1 files. Every banner variant prints that string, including1 files serial, which is what one explicit file produces. - Test: the "a new file is in the gate" test passes locally in about 0.3 s.
- Not checked: the local type check failed because
typescriptisn't installed in this sandbox. The forge's check runs the full type check and test suite. - How to try it: run
bun test test/shards.test.ts -t "gate audit". - Open question: I haven't confirmed that the kill fires. The test passes the same way whether or not it does, so I only know the stop string is reachable from reading
scripts/test-shards.ts.
The flaky test "a new file is in the gate with no list naming it, and explicit files are not audited" had a bug in its second half, and I fixed it. I haven't confirmed the fix holds when the machine is loaded.
Cause. The test runs the shard script twice and kills it once the audit has passed. The earlier fix (#5698) stopped both runs at the text
matrix slice. But the second run names its files explicitly, so it has no slice banner. Nothing stopped it, so it went on to launch a realbun teston an empty file. That is fast on an idle machine and slow on a loaded one, which pushes it past the 30 s timeout. That would explain why it failed on 3 pulls without any change to the code under test.Change. In
test/shards.test.ts:681, the explicit-files run now stops attest-shards: 1 files in. The script prints that banner on stderr before it spawns anything. The test's assertions are the same.Checks. All 6 gate-audit tests that can run here pass; the new-file test takes about 0.3 s. A seventh test in the same group fails because
typescriptisn't installed in this sandbox. The type check failed for the same missing-dependency reason, so it didn't check anything here. The forge's check will cover both.I did not touch
scripts/test-shards.ts.Closes #5864