fix(rivetkit): log and surface actor startup failures

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

_{change wyxwxpum}

[claude]

Review

Small, well-scoped fix to run_actor in rivetkit-rust/packages/rivetkit/src/start.rs. Wrapping the startup phase (input decode -> state creation -> create -> on_create -> on_start) in a single fallible block so failures reach the startup_ready handshake instead of silently dropping the sender is the right fix.

Verification

• Confirmed the bug this fixes is real: previously, an error from A::create_state/A::create/on_create/on_start propagated via ? straight out of run_actor, dropping startup_ready without a reply. The receiver in rivetkit-cores ActorTask::spawn_run_handle (task.rs:1348-1353) would then see a closed channel and surface a generic "receive runtime startup ready reply" error instead of the real cause.
• The fix pattern (RivetError::extract + anyhow::Error::new(...) on the error branch, raw error on the success branch/final return) matches the existing precedent in registry.rs::build_factory (the wrap_start failure path) and the NAPI adapters run_preamble handling in napi_actor_events.rs, so this brings the Rust wrapper manual-startup-ready handshake in line with both. It also matches the rivetkit-core CLAUDE.md rule: forward existing anyhow::Error across lifecycle/action replies by preserving structured RivetError data with RivetError::extract instead of stringifying it.
• The eventual return Err(error) still returns the raw, un-extracted error as the run_actor future result, which is what handle_run_handle_outcome in task.rs logs via log_actor_error when it drains the run handle, consistent with the comment claim.
• Tabs/formatting and comment style match CLAUDE.md conventions (complete sentences, no dashes).

Nits (non-blocking)

• The new test run_actor_invalid_input_fails_to_start only exercises the input-decode failure branch. Since the whole point of the change is that create/on_create/on_start failures now share the same forwarding path, a second test that fails inside on_start (or on_create) would directly confirm the refactor did not just happen to work for the one branch that was reachable before this change too.
• Minor duplication: the "extract + reply to startup_ready + return original error" pattern now exists in both registry.rs::build_factory (for wrap_start errors) and here (for the body of run_actor). Not worth abstracting for two call sites, just noting for awareness if a third one shows up later.

No correctness, security, or performance issues found. The change is on the actor startup path only (not a hot loop), and the extra Result wrapping/await has negligible cost.