RivetKit action can hit closed SQLite coordinator immediately after local engine restart

[stumptowndoug]

Description

With RivetKit 2.3.10 and the bundled rivet-engine 2.3.10, an actor action invoked immediately after restarting the local engine/registry failed once with SQLite transaction coordinator is closed. Retrying the same action after a short delay succeeded. The engine log suggested this happened while the actor generation was syncing.

Environment

• RivetKit: 2.3.10
• rivet-engine: 2.3.10 from @rivetkit/engine-cli
• Runtime: Bun 1.3.14
• Platform: macOS arm64
• Actor database: embedded SQLite via rivetkit/db/drizzle

Reproduction sequence

1. Start a local registry with registry.start() and let RivetKit spawn/reuse the local engine.
2. Create an actor and call an action that reads its embedded SQLite database.
3. Stop the Bun registry process and restart the local engine/registry.
4. Immediately call the same actor action from a separate client process.
5. The first call can fail with SQLite transaction coordinator is closed; a short delayed retry succeeds.

I have only observed this once so far, so the timing window is transient rather than a deterministic reproduction.

Workaround

A client-side retry limited to this exact error, with short bounded backoff (100/250/500 ms), handles the observed failure.

Is this a known actor-generation synchronization race, and is there a readiness signal or more specific structured error code clients should use instead of matching the message?

[linear]

RVT-6374

[stumptowndoug]

Additional observation while running the isolated long-run proof: on Ctrl-C of the Bun registry after the run completed, the registry logged the same transaction_closed chain while syncing the scheduled actor alarm (SELECT MIN(trigger_at) FROM _rivet_schedule_events). This shutdown-path log was deterministic in that run, even though the original client-visible restart failure was not. The actor had a cron/schedule database configured.

[mwaltzer-fx]

I reproduced the shutdown path with RivetKit 2.3.11-rc.5 and the matching N-API package on Linux x64.

A minimal actor completed one workflow step. The process then stayed clean for 15 seconds. await registry.shutdown() caused the same deterministic error:

sqlite operation failed ... operation=query sql="SELECT MIN(trigger_at) FROM _rivet_schedule_events" ... code=transaction_closed
failed to sync scheduled actor alarm ... SQLite transaction coordinator is closed.

The release candidate fixes the destroy order in finish_shutdown_cleanup_with_ctx. The sleep path still calls cancel_local_alarm_timeouts() after SQLite cleanup. This order can permit a scheduled-alarm synchronization after the coordinator closes. Please include a registry-shutdown test with an actor that completed a workflow.