Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:39d89j4f7b is past its budget: trevato/forge: "a pull whose review loop is spent is the planner's (#1655) > the planner is asked for it and its brief … #4054
Check · Review · Land · Live done — Landed and live in production.
The fix for this is already on the branch (`420bf9ed`, pushed), and I've added nothing new.
shipped production is serving it deploy 93e874d
The fix for this is already on the branch (420bf9ed, pushed), and I've added nothing new.
The spent-pull planner test in test/crew-parks-planner.test.ts could fail under load. The crew's own tick sometimes asked the planner before the pull was spent. The test now starts the crew only after the three changes-requested reviews are in, so it no longer depends on timing. It still accepts either outcome from driveRepo ("planned" or "idle"), because the crew's tick may ask the planner first. It still checks that the planner's brief names the pull and carries the third review's text.
I couldn't reproduce the failure here. The test passed six runs in a row, and eight runs in parallel under CPU load. I never saw the failing CI log, so I can't confirm this was the cause.
Main only has the earlier commit 9354dbb5, not this fix. That is why Sentinel still shows the test failing on pulls (11 in the last hour, per the issue body). It should clear once this pull merges and main's check goes green. If the test still fails after that, I need the failing CI log to find the real cause.
To try it: bun test test/crew-parks-planner.test.ts.
Test-only change that removes a real race: the crew used to start in beforeAll and could tick the planner before the pull was spent. It now starts after the handedOverPulls assertion, and afterAll guards the not-yet-started crew with crew?.stop(). No app surface changes, so there is nothing for a phone, keyboard or screen reader to hit. Next: (1) assert the crew has not asked the planner before it starts, so the ordering is pinned and not just commented; (2) make the "asked once" claim strict by counting planner runs, instead of accepting planned or idle.
The fix for this is already on the branch (
420bf9ed, pushed), and I've added nothing new.The spent-pull planner test in
test/crew-parks-planner.test.tscould fail under load. The crew's own tick sometimes asked the planner before the pull was spent. The test now starts the crew only after the three changes-requested reviews are in, so it no longer depends on timing. It still accepts either outcome fromdriveRepo("planned" or "idle"), because the crew's tick may ask the planner first. It still checks that the planner's brief names the pull and carries the third review's text.I couldn't reproduce the failure here. The test passed six runs in a row, and eight runs in parallel under CPU load. I never saw the failing CI log, so I can't confirm this was the cause.
Main only has the earlier commit
9354dbb5, not this fix. That is why Sentinel still shows the test failing on pulls (11 in the last hour, per the issue body). It should clear once this pull merges and main's check goes green. If the test still fails after that, I need the failing CI log to find the real cause.To try it:
bun test test/crew-parks-planner.test.ts.Closes #4041