Seed the scheduler revocation fixture in one Durable Object invocation

[RenKoya1]

ScheduleDriver > permanently fences mutations and cleans revoked storage in bounded alarm passes has to leave behind more rows than a single #cleanupRevokedAccount pass clears, so it enables sixty schedules first. It did that as sixty separate runInDurableObject round-trips, and that setup is where nearly all of the test's runtime went.

That put it uncomfortably close to vitest's 5s default: on an idle machine it measured 2.9s–4.3s, and under the CPU contention of the full pnpm -r test it exceeded the timeout outright.

Enabling them inside a single invocation keeps the test identical in substance — it is still the real enable() path, so every schedule still gets its caps: row and the cleanup assertions are untouched — while removing the round-trip cost.

Verification

Duration of that test within a full schedule-driver.test.ts run, three runs each, same machine, nothing else running:

	run 1	run 2	run 3
main	2939ms	3156ms	4310ms
this branch	1013ms	1091ms	1016ms

pnpm exec tsc --noEmit is clean. The one remaining failure in this file on this branch is bounds callback concurrency and immediately continues a due backlog, which is a separate assertion flake addressed in #103; the two branches touch different regions of the file and merge cleanly.

[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

[ndisidore]

@ask-bonk review this

[ask-bonk]

The change is a faithful inlining. It calls the same instance.enable(activation, testInitiator(instance), now) that enableSchedule performs, just batched into one runInDurableObject rather than 60. testInitiator(instance) is still called per-schedule (correctly, since it mints a fresh entrypoint each time, exactly matching prior behavior). The activationTime is passed for both now and spec.anchorMs — same as before. The revoke/disable/stale-enable/cleanup assertions below are untouched.

One thing to consider: the PR description mentions a separate flaky test (bounds callback concurrency...) tracked in #103, which is out of scope here.

LGTM!

github run