fix(envoy-client): ack start commands immediately instead of waiting for the periodic tick

[MasterPtato]

No description provided.

[MasterPtato]

Stack for rivet-dev/actors

• #5670 fix(rivetkit): surface native runtime load failures instead …
• #5667 fix(envoy-client): fail sent vfs sqlite requests on disconne …
• #5666 fix(rivetkit-core): report actor crashes as a sleep intent i …
• #5668 fix(envoy-client): ack start commands immediately instead of … 👈
• main

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

_{change wnpzrsks}

[railway-app]

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

Service	Status	Web	Updated
website	❌ Build Failed (View Logs)	Web	Sep 4, 2026 at 11:07 pm UTC
kitchen-sink	😴 Sleeping (View Logs)	Web	Sep 4, 2026 at 8:21 pm UTC
frontend-inspector	😴 Sleeping (View Logs)	Web	Sep 4, 2026 at 8:20 pm UTC
frontend-cloud	😴 Sleeping (View Logs)	Web	Sep 4, 2026 at 8:17 pm UTC
ladle	✅ Success (View Logs)	Web	Sep 4, 2026 at 8:12 pm UTC
mcp-hub	✅ Success (View Logs)	Web	Sep 4, 2026 at 8:10 pm UTC

[claude]

Review

Small, well-scoped fix. Generalizing the immediate ack from "stops only" to "the whole raw batch" is the right call: a CommandStartActor left unacked stays in the engines ActorCommandKey subspace and gets re-streamed by envoy_conn_prepare on every reconnect, so a start could be replayed up to ACK_COMMANDS_INTERVAL_MS (5 minutes) later. If the envoy process itself restarted in that window (losing the in-memory processed_command_idx dedup), the replayed start would re-run and could duplicate or resurrect an actor, a real violation of the single-writer actor exclusivity invariant.

Re-verified against the latest commit (f55b414); the diff is unchanged from the version reviewed earlier and the analysis below still holds.

Code quality

• Renaming stopped_actors/send_stop_command_acks to batch_actors/send_batch_command_acks is accurate and the updated doc comments correctly describe the new scope and the still-open dedup-clear race (nice touch keeping that caveat intact).
• batch_actors is still collected before the dedup/skip loop, so a replayed (skipped) command of any kind is still re-acked, consistent with the original stop-only behavior.

Correctness

• Traced through the multi-command-per-batch case (e.g. start then stop for the same actor/generation in one batch): send_batch_command_acks reads the final value from ctx.processed_command_idx, so it naturally acks the highest processed index rather than double-sending. Looks correct.
• Widening this to "every command in the batch" is future-proof if a new Command variant is added later, since batch_actors is not filtered by variant, and the match arms are still exhaustive per repo convention with no _ fallback.

Test coverage

• start_command_is_acked_immediately mirrors the existing stop_command_is_acked_immediately test well, including asserting dedup is retained (not cleared) after the immediate ack.
• One gap: there is no test exercising a single batch containing both a start and a stop for the same actor/generation, which would directly exercise the highest-map collapsing behavior in send_batch_command_acks. Not blocking, but would be a nice addition given that is the trickiest part of this change.
• The core "process restart loses dedup and replay resurrects actor" scenario this PR is really guarding against is not (and cannot easily be) unit-tested at this level, since it requires losing in-memory state entirely. Worth a mention in the PR description if not already covered by broader integration/e2e coverage elsewhere.

Performance

• Negligible. This trades a few extra websocket sends (one per batch containing a start, which happens once per actor lifecycle) for closing a correctness gap. Reasonable trade-off.

Security

• No new concerns. This is internal envoy to engine ack bookkeeping on the trusted side of the envoy/pegboard-envoy boundary; no untrusted input handling changes here.

No blocking issues found.