fix(rivetkit-core): always signal actor stop handle on teardown failure

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5593 fix(rivetkit-core): always signal actor stop handle on teard … 👈
• #5603 fix(rivetkit): expose engine ray IDs on errors for debug
• main

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

_{change xyxnuuus}

[railway-app]

🚅 Deployed to the actors-pr-5593 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
kitchen-sink	✅ Success (View Logs)	Web	Aug 31, 2026 at 5:26 pm
website	❌ Build Failed (View Logs)	Web	Aug 31, 2026 at 5:25 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Aug 26, 2026 at 1:34 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Aug 25, 2026 at 9:20 am
ladle	✅ Success (View Logs)	Web	Aug 24, 2026 at 2:46 pm
mcp-hub	✅ Success (View Logs)	Web	Aug 24, 2026 at 2:44 pm

[claude]

Review: fix(rivetkit-core): always signal actor stop handle on teardown failure

Summary
This fixes a real bug: previously, shutdown_started_instance used ? on the join outcome (join.await.context(...)?.context(...)?), so a failing actor task join would early-return before stop_handle.complete()/stop_handle.fail() was ever called. That drops the stop_handle oneshot unsignaled, and any waiter (e.g. an envoy caller awaiting the stop handle) would see a generic "channel closed" error instead of a structured RivetError. The fix folds the join result into final_result alongside shutdown_result so the stop handle is always signaled on the way out, matching the "Fail-By-Default Runtime" guidance in CLAUDE.md (no early-return around required lifecycle/teardown signaling).

Correctness

• The refactor is sound: join_result and shutdown_result are computed independently, then combined with .and(...), and stop_handle is signaled unconditionally afterward via match &final_result. RivetError::extract(error) correctly takes &anyhow::Error, matching the borrow from match &final_result { Err(error) => ... }.
• Priority when both shutdown_result and join_result fail: shutdown_result wins via .and(...), and the discarded join error is logged via tracing::warn! with structured fields (discarded_join_error) rather than silently dropped, matching the structured-logging convention in CLAUDE.md.
• instance.ctx.configure_lifecycle_events(None) still runs unconditionally after the join, same as before; no behavior change there.

Test coverage gap
No regression test exercises this exact fix. tests/modules/registry.rs::stop_actor_for_test bypasses shutdown_started_instance/RegistryDispatcher::stop_actor entirely: it calls ActorLifecycle::shutdown_for_sleep/shutdown_for_destroy directly and never touches instance.join or stop_handle. So there is currently no test that would catch a regression back to the old ?-early-return behavior, for example if this function gets refactored later and the ? is reintroduced, stop_handle would silently go unsignaled again with no test failure. Given the bug being fixed is precisely that stop_handle was not reliably signaled, it would be worth adding a test that forces the actor task join to fail (or drops it) and asserts stop_handle still resolves with a structured error rather than hanging or surfacing a channel-closed error.

Minor

• The log message says "only the shutdown error is returned." Worth keeping in mind that the log wording and the actual .and(...) precedence are two separate pieces of code that could silently drift out of sync in a future change.

Overall this is a small, well-scoped, low-risk fix in the right place (rivetkit-core, per the layer architecture rules). The main gap is test coverage for the exact failure mode being fixed.