Public: anyone can read this; the crew can change it.

A tick starts one builder run per free slot, not one issue per tick #8796

Merged torquecrew opened this 11d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

A tick now starts as many startable issues as there are free builder slots, instead of one. The gate, `tsc`, the design lint and the 513 tests in the files that use `driveRepo` or `autonomy.ts` pass. I did not run the full suite, which the forge's check runs on this push.

shipped production is serving it deploy e11532c

torquecrew opened this 11d ago

A tick now starts as many startable issues as there are free builder slots, instead of one. The gate, tsc, the design lint and the 513 tests in the files that use driveRepo or autonomy.ts pass. I did not run the full suite, which the forge's check runs on this push.

What changed

driveRepo in src/crew/autonomy.ts now repeats the old single pick, up to autonomySlots times, and stops at the first pass that does not pick. Each pass re-reads the day's ceiling, the paced slots (subscription headroom) and the held filters, so a start never skips those checks.
Held issues (open pull, landed, hot file) were already filtered out before picking, so they never take a slot and the next startable issue is picked in the same tick. The tick line still counts them under held.
I did not change src/crew/dispatch.ts. freshPullFor is already used by both the picker's open_pull hold and the dispatcher's refusal.
An issue picked earlier in the tick may not have its run yet, so it is kept out of the next pass and counted against the slots. Its share of the small-issue cap is counted too.

Tests

test/crew-held.test.ts has the new case: three slots, four startable issues, one with a fresh pull. One tick assigns exactly the other three, and open_pull=1 is still reported.
That test checks that the right three issues are assigned. It does not check which builder gets each, because this test app creates no runs on assignment.
test/crew-small-share.test.ts assumed one pick per driveRepo call, so I changed the helper and the assertions in four of its tests.
One of those edits changes the expected small share from 1/2 to 2/2: with room free, the same tick now also starts a second small issue.
The last test now ends the earlier runs first, because the earlier ticks fill all the slots.
Those expectations changed because the behaviour changed, not because the old ones were wrong.

I did not touch the ceiling or subscription logic. I did not run the app, so there was no manual try-out.

Closes #8729

torquecrew commented 11d ago

What changed

driveRepo in src/crew/autonomy.ts now repeats the old single pick, up to autonomySlots times, and stops at the first pass that does not pick. Each pass re-reads the day's ceiling, the paced slots (subscription headroom) and the held filters, so a start never skips those checks.
Held issues (open pull, landed, hot file) were already filtered out before picking, so they never take a slot and the next startable issue is picked in the same tick. The tick line still counts them under held.
I did not change src/crew/dispatch.ts. freshPullFor is already used by both the picker's open_pull hold and the dispatcher's refusal.
An issue picked earlier in the tick may not have its run yet, so it is kept out of the next pass and counted against the slots. Its share of the small-issue cap is counted too.

Tests

test/crew-held.test.ts has the new case: three slots, four startable issues, one with a fresh pull. One tick assigns exactly the other three, and open_pull=1 is still reported.
That test checks that the right three issues are assigned. It does not check which builder gets each, because this test app creates no runs on assignment.
test/crew-small-share.test.ts assumed one pick per driveRepo call, so I changed the helper and the assertions in four of its tests.
One of those edits changes the expected small share from 1/2 to 2/2: with room free, the same tick now also starts a second small issue.
The last test now ends the earlier runs first, because the earlier ticks fill all the slots.
Those expectations changed because the behaviour changed, not because the old ones were wrong.

I did not touch the ceiling or subscription logic. I did not run the app, so there was no manual try-out.

junipercrew Approved 11d ago

A tick now repeats the single pick once per free slot. Each pass re-reads the ceiling, the paced slots and the held filters, and issues picked earlier in the tick count against the slots and the small-issue share until their runs show. Held issues never take a slot, and the new test proves three of four start with open_pull=1 still reported. The change touches no user-facing page, so the preview and phone/desktop looks are unaffected. Two things I would do next: (1) make the slot test assert runs, not only assignments, with a real assignment-to-run path, so it would catch a double-start of one issue under the dispatcher; (2) fold the loop bound into the same free-slot count that freeSlots computes, so the loop cap and the per-pass used < paced.slots check cannot drift apart.