fix(rivetkit-core): cancel driver alarm before sqlite teardown on destroy

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5556 fix(container-runner): read cgroup v1 memory usage under gvi …
• #5548 feat(container-runner): log version and git sha at actor sta …
• #5549 feat(container-runner): setup instance memory and cpu usage …
• #5546 fix(rivetkit): keep actor event loop alive through shutdown …
• #5539 feat(container-runner): report actors as crashed on unexpect …
• #5536 feat(container-runner): log unexpected platform SIGTERM as a …
• #5530 fix(rivetkit-core): cancel driver alarm before sqlite teardo … 👈
• #5531 feat(container-runner): keep instance warm instead of self-e …
• #5533 chore(container-runner): default stop grace to 10s
• #5528 fix(rivetkit): log and surface actor startup failures
• #5558 fix(sdks): drop rivet-util metrics dep from protocol crates …
• main

Get stack: forklift get 5530
Push local edits: forklift submit
Merge when ready: forklift merge 5530

_{change qprwzozl}

[claude]

Review

Small, well-scoped fix. Reading through finish_shutdown_cleanup_with_ctx and the schedule.rs alarm-write plumbing to confirm the reasoning:

The fix is correct. cancel_driver_alarm_logged() calls set_alarm_tracked(..., None, ...), which spawns a task that awaits the envoy ack and then calls persist_last_pushed_alarm(...), pushing the completion receiver into schedule_pending_alarm_writes. Previously, for ShutdownKind::Destroy, this call happened after wait_for_pending_alarm_writes() (and after the SQLite cleanup step), so the spawned persist write was never tracked or awaited by anything, and could still be in flight when ctx.sql().cleanup_for_shutdown(...) tore down the actor's SQLite connection. Moving the call up so it runs before wait_for_pending_alarm_writes() ensures that write is registered and awaited before SQLite teardown, closing the race. The Sleep branch is untouched, consistent with the documented behavior of keeping the persisted engine alarm armed across sleep and only aborting the local timer.

The match arms stay exhaustive over ShutdownKind in both blocks, consistent with the repo convention of never using a _ => fall-through on enum matches.

Suggestions (non-blocking)

1. Test coverage gap: the existing destroy_shutdown_still_clears_driver_alarm_after_cleanup test only asserts test_driver_alarm_cancel_count() == 1; it does not exercise the actual race being fixed (a slow or delayed alarm ack causing the persist write to still be in flight when SQLite cleanup runs). Since this fixes a real ordering bug, a regression test that holds the ack open and asserts SQLite cleanup does not proceed until the persist write completes would make the fix self-verifying and guard against silent regression.
2. Stale test name: destroy_shutdown_still_clears_driver_alarm_after_cleanup was named when the cancel call ran after the SQLite cleanup step; it now runs before. Worth a rename in a follow-up so the name does not mislead readers about ordering.
3. The PR description is empty. For a shutdown-ordering or race fix like this, a one-line description of the observed symptom would help future readers understand motivation without digging through schedule.rs.

No security, performance, or style concerns beyond the above. The change is minimal and correctly targeted at the described race.