fix(rivetkit): log and surface actor startup failures

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

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

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

_{change wyxwxpum}

[claude]

Review

Summary: run_actor now wraps input decode / state creation / create / on_create / on_start in one fallible block so a startup failure is forwarded through startup_ready (via RivetError::extract) instead of silently dropping the oneshot sender. Previously a failed startup left startup_ready_rx seeing a closed channel, so spawn_run_handle in task.rs surfaced a generic "receive runtime startup ready reply" error instead of the real cause.

Correctness

• The fix is sound. I traced the consumer in rivetkit-core/src/actor/task.rs::spawn_run_handle (awaits startup_ready_rx and wraps with .context("runtime startup preamble")), and the pattern used here (anyhow::Error::new(RivetError::extract(&error))) exactly matches the existing precedent in registry.rs::build_factory for wrap_start failures, and in the NAPI adapter (rivetkit-napi/src/napi_actor_events.rs::run_adapter_loop). This PR is effectively closing a parity gap between the Rust wrapper and the already-correct NAPI path.
• The comment claiming "the failure itself is logged by rivetkit-core when it drains the run handle" checks out. spawn_run_handle sets self.run_handle before awaiting startup_ready_rx, so even though start_actor() returns early on failure, the main run_live select loop still later selects on wait_for_run_handle and logs via handle_run_handle_outcome -> log_actor_error.
• The raw (non-extracted) error is still returned from run_actor via return Err(error), so existing callers/tests that assert on the original error text (e.g. contains("decode actor input from cbor")) keep working. Only the startup_ready reply gets the sanitized/structured version, consistent with the CLAUDE.md guidance on preserving RivetError data across lifecycle replies.

Minor nit

• The updated test (run_actor_invalid_input_fails_to_start) only asserts ready_rx.await...expect_err(...) without checking the structured error's group()/code(). Other tests in this file (e.g. run_actor_action_errors_and_unknown_action_are_structured) do assert on RivetError::extract(&error).group()/.code(). Not required, but asserting the extracted error's shape here would give a bit more confidence that RivetError::extract is doing something meaningful for this path (input-decode errors go through build_internal, so group()/code() would be the generic internal-error code) rather than just "channel got some error."

Other

• No security, performance, or logging-convention concerns. The change is small and well-scoped with a clear justifying comment and no incidental refactoring. Test coverage for the new behavior is adequate.

Nice fix. Small, targeted, and directly addresses a real diagnostic gap where a startup failure previously surfaced as an opaque "channel closed" error rather than the actual cause.