[rmcdaniel]

Review tier C: test only. It adds one crate-internal test module and changes no runtime code.

Fixes #959.

The schedules guide (durable-workflow.github.io#421) says native Server starts up to 100 due schedules per pass, ordered by next_fire_at. A burst of N therefore fires within ceil(N / 100) passes, in due order. That was derived from source and had no test.

Test

runtime::schedule_burst_tests is a new #[cfg(test)] module on SQLite. It is separate from schedule_execution's tests so it doesn't collide with #995. One pass is one fire_due_schedules call, as one maintenance tick makes.

• Setup: 250 schedules on a yearly cron, so none can come due twice during the test. All are made due with distinct next_fire_at values, in the reverse of creation order, so ordering by id would give a different sequence.
• Each pass fires exactly the next 100 schedules in next_fire_at order: 100, then 100, then 50. The burst needs exactly 3 passes, which is ceil(250/100).
• No replay: a fourth pass fires nothing. Every schedule has fires_count = 1, there are 250 runs, and each schedule has exactly one ScheduleTriggered event, at its own stored occurrence.

The bound matches the guide, so no code or docs change is needed.

Counterfactuals, applied to fire_due_schedules locally: ordering the due batch by id, or batches of 50, each fail the test. The test passes in about 0.7 s on lab2 with 1.99.0 and -j2.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

Tier C receipt. Hosted checks are terminal at exact head 58fcbde1ce42b0f1eda2831fbc2b6109b97480e5 (tree c0b7978eb8d5ef4b1ede62e485157669b362145a): 57 passed, 1 skipped (the expected one), 0 failed. The change is test-only: rust/src/runtime/schedule_burst_tests.rs (new, #[cfg(test)]) plus its module declaration in rust/src/runtime/mod.rs.