feat(container-runner): keep instance warm instead of self-exiting

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #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
• #5529 fix(rivetkit): treat empty actor input bytes as absent
• main

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

_{change qqzrqpro}

[claude]

Review

Reviewed the container-runner "stay warm" change (container-runner/src/actor.rs, container-runner/src/main.rs, README, docs). The core logic reads cleanly and the removal of request_exit() calls from stop_child/on_start is consistent with the new "engine reaps via /start drain" model, which is a real, existing engine mechanism (request_lifespan / drain_grace_period in pegboard/src/workflows/serverless/conn.rs), so the premise checks out.

A few things worth a look:

1. Stale doc comment on EXIT (container-runner/src/main.rs:67-69):

   /// Cancelled to bring the whole process down (actor stopped, failed start, or
   /// signal). main owns the exit sequencing.
   static EXIT: LazyLock<CancellationToken> = LazyLock::new(CancellationToken::new);

   This was not updated and now directly contradicts the new comment on request_exit a few lines below ("Only the platform shutdown signal drives this now: actors stopping or failing to start no longer exit the instance"). Worth fixing so the two comments do not disagree.

2. Test coverage gap for the core new behavior: container-runner/examples/e2e-test/host/run-host-tests.sh scenario 6 (graceful destroy) still just destroys the actor and shuts the runner down immediately afterward, with no assertion that the runner process actually survives past the last actor on_destroy (no self-exit) and can accept a second placement on the same warm instance. Since "stay warm and reuse the instance" is the entire point of this PR, it would be good to add a scenario that destroys an actor, confirms the runner is still alive/serving /health, then creates a second actor against the same runner process to confirm reuse actually works end to end.

3. Design question, not a blocker: previously, on_start failed-child-spawn path called request_exit when the instance was otherwise idle, explicitly to avoid handing a "poisoned" instance (broken environment, missing binary, etc.) the next placement. That guard is now gone; a failed start always leaves the instance warm and eligible for reuse. If the failure is systemic rather than actor-specific, the same instance could keep receiving new placements and failing them repeatedly for as long as request_lifespan allows. Worth confirming the engine has its own runner-health/backoff signal so it does not keep routing to an instance that just failed a start, since the runner no longer self-removes from rotation in that case.

4. Minor nit: with request_exit only remaining caller (spawn_signal_handler) always setting SIGNAL_SHUTDOWN before cancelling EXIT, the else branch in async_main shutdown handling (main.rs:373-376) is now truly unreachable. The comment explaining it is kept as a deliberate fallback for a future actor-driven exit path is reasonable, but flagging in case the team prefers to delete it until it is actually needed again, per the repo general preference against speculative/dead code paths.

No security concerns (no new input handling), and the docs/README/mdx updates accurately describe the new behavior.