fix(rivetkit-core): honor ctx.destroy() requested during a sleep grace

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5537 fix(rivetkit-core): honor ctx.destroy() requested during a s … 👈
• #5535 feat(container-runner): destroy actor on sleep instead of pa …
• #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 5537
Push local edits: forklift submit
Merge when ready: forklift merge 5537

_{change vkuumrxz}

[claude]

Review: honor ctx.destroy() requested during a sleep grace

Small, well-scoped fix. Confirmed it lines up with the documented invariant in docs-internal/engine/sleep-sequence.md and the comment in context.rs::request_stop ("destroy is a stronger signal that escalates an in-flight sleep"), and with task.rs:707-720's debug_assert!("engine actor2 sends one Stop per actor instance") since the engine will not send a second Stop for the same generation, so escalating locally via the destroy_requested flag is the right mechanism.

Test coverage (main gap)

No test was added. This change touches sleep/destroy grace finalization, which rivetkit-core's own conventions call out as needing pinned coverage (docs-internal/engine/sleep-sequence.md: "Rust integration tests ... pin predicate behavior, grace period selection"). The existing pattern in tests/modules/task_lifecycle.rs::sleep_shutdown_aborts_stuck_run_handler_at_grace_deadline (spawn task.handle_stop(ShutdownKind::Sleep), then drive time/state) is a good template: start an actor, enter SleepGrace, call ctx.destroy() mid-grace, and assert the actor finalizes with ShutdownKind::Destroy semantics (e.g. LifecycleState::Destroying, mark_destroy_completed, or via the #[cfg(test)] run_shutdown_reply_hook/run_shutdown_cleanup_hook hooks already wired into task.rs). Worth adding before merge given how easy this class of regression is to reintroduce silently.

One thing worth double-checking with the author

finalize_shutdown_reason is only applied at the two LiveExit::Shutdown construction sites (try_finish_grace, on_sleep_grace_deadline). The readiness check that gates when finalization happens still calls can_finalize_shutdown(grace.reason) with the original, unescalated reason. can_finalize_shutdown treats Destroy more leniently than Sleep (it skips the !run_handler_active() requirement, see sleep.rs:273-284), so an actor that calls ctx.destroy() mid-SleepGrace while its run handler is still active keeps waiting on Sleep's stricter predicate (bounded only by the grace deadline) instead of immediately becoming eligible to finalize as Destroy. That may be intentional and safer (avoid abruptly cutting through user code just because destroy was requested), but the fix as written only escalates the outcome (cleanup path, lifecycle state, alarm handling), not the readiness gate. Worth a short comment or explicit confirmation from the author that this is the intended scope, since a future reader could reasonably expect both to escalate together.

Nits

• The new finalize_shutdown_reason doc comment is clear and matches the codebase's comment-style conventions (complete sentences, explains the why).
• record_shutdown_timeout(grace.reason) and the grace-deadline warn log at task.rs:1571-1587 still use the pre-escalation reason label, which looks intentional (it documents the grace period the deadline was actually measured against) rather than an oversight, just flagging since it sits adjacent to the changed lines.

No security, performance, or style concerns beyond the above. The change itself is minimal and correctly scoped to rivetkit-core per the layer-architecture rules (no logic duplicated in NAPI/TS).