Make the scheduler delivery-bound assertion deterministic

[RenKoya1]

ScheduleDriver > bounds callback concurrency and immediately continues a due backlog asserts maxActiveCallbacks === DELIVERY_CONCURRENCY, but the observed peak is a function of timing rather than of the bound: each of the four runBounded lanes runs startHook -> authorizeObservation -> onSchedule over RPC, and the callback only holds for 10ms. When the lanes drift apart the peak lands below 4 even though the runner never exceeds it.

Reproducible on macOS/arm64 (M-series):

AssertionError: expected 3 to be 4 // Object.is equality
 ❯ __tests__/schedule-driver.test.ts:735:41

Rather than weaken the assertion to an upper bound — which would stop proving the bound is reached — this holds each callback until a full set of lanes has arrived, so the peak is the runner's bound and not RPC scheduling.

The batch of 20 delivers as exactly five full rounds of four, so the barrier waits on a count that is guaranteed to arrive and needs no timeout of its own; the tail round of one is excluded by the limit argument. The barrier is off by default, leaving every other test untouched.

Verification

Four consecutive runs of schedule-driver.test.ts, alternated on the same machine with nothing else running:

	run 1	run 2	run 3	run 4
main	fail	fail	pass	fail
this branch	pass	pass	pass	pass

pnpm test for the package is 102 passed / 3 skipped, and pnpm types:check is clean.

Unrelated, and untouched here: permanently fences mutations and cleans revoked storage in bounded alarm passes occasionally exceeds the 5s vitest timeout under CPU contention (it showed up on main run 4 above, and on this branch too when the whole monorepo suite runs in parallel). That is a separate load sensitivity, not the assertion this PR is about.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[RenKoya1]

I have read the CLA Document and I hereby sign the CLA

[snowyukitty]

I verified this on Windows, where the assertion this PR makes deterministic is a recorded failure: at 3562627, issue #251 documented expected maxActiveCallbacks 2 to be 4 in this exact test when the scheduler suite runs under full-suite package concurrency (Windows 11, Node 22.22.3, pnpm 11.17.0 — RPC legs drift the lanes apart by more than the 10ms hold).

With c5fbf7b cherry-picked onto current main (4288713), on the same host:

• vitest run (workerd config) in gatekeeper-scheduler, 5 consecutive standalone runs: 7 files, 102 passed | 3 skipped, every time.
• vp run --filter "./packages/**" --no-cache test — all 22 package test tasks concurrently, after building typed-storage — fully green, including this suite under the same cross-package contention that produced the 2-vs-4 failure before. An earlier run of the same command without that prior build also passed this suite (its only failure was workshop-backend unable to resolve the unbuilt typed-storage entry, which is expected locally since vp run test deliberately never triggers builds).

Reading the barrier, two details hold up well: a callback pushes its schedule ID before checking callbackScheduleIds.length > callbackBarrierLimit, so exactly the first 20 deliveries are barriered regardless of delivery order, and a waiter counts itself in activeCallbacks, so four blocked lanes release one another with no external nudge.

One liveness edge seems possible in principle, though none of the runs above ever hit it: a barriered callback can pass the barrier early by observing activeCallbacks == 4 while up to three earlier callbacks are still inside their 10ms hold — piggybacking on sleepers instead of waiting for its own full round. Each early pass shifts the round alignment. Stranding additionally needs the lanes to go quiet after the shift rather than keep the pipeline 4-wide — but the same RPC drift that produced the 2-vs-4 failure makes both halves plausible on a slow host. If that leaves only one or two barriered callbacks at the tail, they can never see a count of 4: the 21st delivery contributes one transient active, which rescues a tail of three waiters but not of one or two, and the test would then time out instead of failing. If you want the barrier structurally immune to that, setCallbackBarrier(4, 4) looks sufficient: the first four deliveries occupy all four lanes and none can finish before all four coexist, which already proves the peak equals the bound, is independent of any later round alignment, and leaves the backlog-continuation behavior of the remaining deliveries exactly as it is today. Non-blocking either way given it never reproduced here.

AI tools performed this verification and analysis under human direction; the commands and counts above are from local runs on this machine.