Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:jjjg6k07pv is past its budget: trevato/forge: "choosing how a forge follows its parent > (unnamed)" failed on 3 pulls in the last hour — the lane's re… #4530
Check · Review · Land · Live done — Landed and live in production.
This pull hardens the teardown of the three spawn-chain suites, but I could not reproduce the failure, so the root cause is still unconfirmed.
shipped production is serving it deploy 7b21267
This pull hardens the teardown of the three spawn-chain suites, but I could not reproduce the failure, so the root cause is still unconfirmed.
What I found. The "(unnamed)" failure in "choosing how a forge follows its parent" is a setup or teardown hook, not one of the three tests. The sentinel raised this issue at 15:56:52, one second after #4476 merged. #4476 had already raised the beforeAll timeout from 60 s to 240 s, and that fix was also inferred from the sentinel's summary alone. The recurrence may be the sentinel still counting failures from before that merge, but I can't confirm that.
What I tried. test/spawn-chain-mode.test.ts passes in about 1 s here, including three runs with eight busy-loop processes competing for CPU. The three spawn-chain suites together (25 tests) passed three times in a row. A full bun test run had failures in the scaffold typecheck, the merge queue, SSH port, chromium and look suites, which I took to be sandbox limits. None of those failures were in the spawn-chain files.
What changed. In test/spawn-chain.test.ts, test/spawn-chain-doors.test.ts and test/spawn-chain-mode.test.ts:
afterAllnow closesservers,child,rootandgrandwith?.. If setup fails partway, the report shows the setup error instead of a second "cannot read properties of undefined" from teardown.- The temp-directory removal retries (
maxRetries: 5, retryDelay: 100), so a transientENOTEMPTYorEBUSYwhile git or SQLite files are still being released can't fail the hook.
No assertion changed and no source code changed. bun x tsc --noEmit is clean and bun test test/spawn-chain passes (25 tests).
Not done. I did not replace the real spawnForge path in setup with a fixture, because the suites exist to exercise it. If the sentinel flags this cause again after this lands, the next step is to capture the check log of a failing run. It will show whether the failing hook is beforeAll or afterAll, which I can't tell from here.
Test-only change to the afterAll hooks of the three spawn-chain suites. Optional chaining means a failed setup reports its own error instead of a second TypeError from teardown. rm retries cover transient ENOTEMPTY/EBUSY. No assertions or source changed, no new dependency, and nothing touches the security, terminal or README surface. The app preview is unaffected. The pull is honest that the root cause is unconfirmed, and it is a small stability fix for CI.
Two things I would do next:
- If the sentinel flags this suite again, capture the check log first. It will show whether the failing hook is beforeAll or afterAll, which nobody can tell from the summary.
- Check whether the sentinel is still counting failures from before #4476 merged. If so, the window needs to reset at the merge, or this recurs as noise.
This pull hardens the teardown of the three spawn-chain suites, but I could not reproduce the failure, so the root cause is still unconfirmed.
What I found. The "(unnamed)" failure in "choosing how a forge follows its parent" is a setup or teardown hook, not one of the three tests. The sentinel raised this issue at 15:56:52, one second after #4476 merged. #4476 had already raised the
beforeAlltimeout from 60 s to 240 s, and that fix was also inferred from the sentinel's summary alone. The recurrence may be the sentinel still counting failures from before that merge, but I can't confirm that.What I tried.
test/spawn-chain-mode.test.tspasses in about 1 s here, including three runs with eight busy-loop processes competing for CPU. The three spawn-chain suites together (25 tests) passed three times in a row. A fullbun testrun had failures in the scaffold typecheck, the merge queue, SSH port, chromium and look suites, which I took to be sandbox limits. None of those failures were in the spawn-chain files.What changed. In
test/spawn-chain.test.ts,test/spawn-chain-doors.test.tsandtest/spawn-chain-mode.test.ts:afterAllnow closesservers,child,rootandgrandwith?.. If setup fails partway, the report shows the setup error instead of a second "cannot read properties of undefined" from teardown.maxRetries: 5, retryDelay: 100), so a transientENOTEMPTYorEBUSYwhile git or SQLite files are still being released can't fail the hook.No assertion changed and no source code changed.
bun x tsc --noEmitis clean andbun test test/spawn-chainpasses (25 tests).Not done. I did not replace the real
spawnForgepath in setup with a fixture, because the suites exist to exercise it. If the sentinel flags this cause again after this lands, the next step is to capture the check log of a failing run. It will show whether the failing hook isbeforeAllorafterAll, which I can't tell from here.Closes #4506