fix(rivetkit): keep actor event loop alive through shutdown state serialization

[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 5546
Push local edits: forklift submit
Merge when ready: forklift merge 5546

_{change losmyvnt}

[claude]

Review

Summary: handle_actor_event no longer returns Ok(true) from the RunGracefulCleanup arm, so run_actor's event loop keeps draining events after on_sleep/on_destroy runs instead of breaking immediately. All affected inline tests get a drop(tx) to close the channel and let the loop terminate, plus a new regression test.

Correctness — looks right

I traced this against rivetkit-core's ActorTask::run_shutdown (rivetkit-rust/packages/rivetkit-core/src/actor/task.rs):

async fn run_shutdown(&mut self, reason: ShutdownKind) -> Result<()> {
    ...
    self.save_final_state().await?;       // sends SerializeState, awaits reply
    self.close_actor_event_channel();      // only then drops actor_event_tx
    self.join_aborted_run_handle().await;
    ...
}

save_final_state sends ActorEvent::SerializeState after RunGracefulCleanup and blocks on the reply (bounded by SERIALIZE_STATE_SHUTDOWN_SANITY_CAP / the configured sleep grace period), and the channel is only closed afterward. Before this fix, run_actor broke out of its loop as soon as the cleanup event was handled, so it never read the follow-up SerializeState, its reply_rx.await in core would time out, and any state written by on_sleep/on_destroy would silently be dropped in favor of empty deltas. The fix (stay in the loop until the channel closes) matches the actual sequencing and closes a real state-loss bug. The new test run_actor_serializes_state_after_cleanup reproduces exactly this ordering and asserts the on_sleep log entry survives serialization.

Worth noting: the NAPI/TS bridge (rivetkit-typescript/packages/rivetkit-napi/src/napi_actor_events.rs) already handles RunGracefulCleanup by spawning a detached task rather than ending its dispatch loop, so it never had this bug — this brings the Rust flagship wrapper (rivetkit-rust/packages/rivetkit) to parity, consistent with the "keep rivetkit (Rust) up to date with rivetkit-typescript" guidance in CLAUDE.md.

Nit: now-dead Result<bool> / should_stop

With the RunGracefulCleanup arm no longer returning Ok(true), no arm of handle_actor_event returns true anymore (confirmed via grep — the removed line was the only Ok(true) in the match). That makes this in run_actor dead:

while let Some(event) = events.recv_raw().await {
    let should_stop = handle_actor_event(actor.clone(), ctx.clone(), event).await?;
    if should_stop {
        break;
    }
}

handle_actor_event's signature could shrink to Result<()> and the loop simplify to while let Some(event) = events.recv_raw().await { handle_actor_event(...).await?; }, since the loop now exclusively terminates via the channel closing. Not a bug, but worth a follow-up cleanup so the vestigial "can this event stop the loop" branch doesn't confuse future readers into thinking some event type still short-circuits.

Minor test nit

run_actor_serializes_state_after_cleanup (and the shared request_serialize helper) awaits the reply with no timeout. That's fine now, but if this exact regression reappeared, the test would hang instead of failing fast (no reader left to answer the oneshot). Not blocking — CI will still eventually flag a hung test — but a tokio::time::timeout(...) around the reply_rx.await in request_serialize would make a future regression fail with a clear message rather than a stall.

Other

• No security or performance concerns — this is actor-local lifecycle sequencing, not a trust boundary, and the extra loop iteration(s) before shutdown are negligible.
• Test coverage is good: the new test isolates the exact repro (sleep cleanup → serialize before channel close) and the mechanical drop(tx) additions correctly preserve every other existing test's shutdown behavior.