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… #4476
Check · Review · Land · Live done — Landed and live in production.
This raises the `beforeAll` timeout from 60 s to 240 s in the three spawn-chain suites. I couldn't reproduce the failure, so the cause is inferred.
shipped production is serving it deploy 674862e
This raises the beforeAll timeout from 60 s to 240 s in the three spawn-chain suites. I couldn't reproduce the failure, so the cause is inferred.
Cause. The failing "(unnamed)" entry in "choosing how a forge follows its parent" is the suite's beforeAll hook. That hook creates a repo, commits to it, runs spawnForge (which does a git fetch) and boots a child app. It has a 60 s cap, and on a loaded check machine the git work can run past it. The three pulls failed because their setup took longer than the cap, not because of anything in their code.
Change. The same 60 s hook cap was in test/spawn-chain-mode.test.ts, test/spawn-chain-doors.test.ts and test/spawn-chain.test.ts, so I raised all three to 240 s. Only the first was named in the issue. No assertion changed.
Not done. I did not remove the git work from the setup. The suites test the real spawn path, and a faster setup would mean a fixture that stands in for it. The only evidence is the sentinel's summary, since no failure log was available. If the sentinel flags this lane again after the push, the cause is something other than setup time.
Check. bun test test/spawn-chain passes locally: 25 tests, 0 failures, in about 6 s. I did not run the full check, since the forge runs it on the push.
Test-only change: the beforeAll cap goes from 60 s to 240 s in the three spawn-chain suites. No app code, page, or door is touched, so there is nothing in the preview to exercise and no security surface. It fits priority 1 (stability of the merge lane). The three files get the same one-line change, and no assertion changed.
Two things I would do next:
- The cause is inferred from the sentinel summary, not from a log. If the lane trips again, capture how long the setup actually took. Log the elapsed time of the spawnForge fetch and child boot in the hook so the next failure shows whether it was slowness or a hang. A 240 s cap on a real hang only makes the failure slower.
- Move the repeated 240_000 into one shared named constant in a test helper, so the next adjustment is one edit and not three.
This raises the
beforeAlltimeout from 60 s to 240 s in the three spawn-chain suites. I couldn't reproduce the failure, so the cause is inferred.Cause. The failing "(unnamed)" entry in "choosing how a forge follows its parent" is the suite's
beforeAllhook. That hook creates a repo, commits to it, runsspawnForge(which does agit fetch) and boots a child app. It has a 60 s cap, and on a loaded check machine the git work can run past it. The three pulls failed because their setup took longer than the cap, not because of anything in their code.Change. The same 60 s hook cap was in
test/spawn-chain-mode.test.ts,test/spawn-chain-doors.test.tsandtest/spawn-chain.test.ts, so I raised all three to 240 s. Only the first was named in the issue. No assertion changed.Not done. I did not remove the git work from the setup. The suites test the real spawn path, and a faster setup would mean a fixture that stands in for it. The only evidence is the sentinel's summary, since no failure log was available. If the sentinel flags this lane again after the push, the cause is something other than setup time.
Check.
bun test test/spawn-chainpasses locally: 25 tests, 0 failures, in about 6 s. I did not run the full check, since the forge runs it on the push.Closes #4462