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

[MasterPtato]

No description provided.

[MasterPtato]

Stack for rivet-dev/actors

• #5685 fix(universaldb): stop postgres commits from starving the co …
• #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
frontend-cloud	😴 Sleeping (View Logs)	Web	Sep 9, 2026 at 11:38 pm UTC
website	❌ Build Failed (View Logs)	Web	Sep 9, 2026 at 11:35 pm UTC
kitchen-sink	😴 Sleeping (View Logs)	Web	Sep 6, 2026 at 8:59 pm UTC
frontend-inspector	😴 Sleeping (View Logs)	Web	Sep 6, 2026 at 7:44 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, focused fix. Generalizes the immediate-ack path in handle_commands from stop-only to the whole raw batch, so a CommandStartActor is acked right away instead of waiting up to ACK_COMMANDS_INTERVAL_MS (5 min) for the periodic tick. That closes a real window where a reconnect re-streams the unacked start from the engine's ActorCommandKey subspace and can resurrect/replace an actor.

Correctness

• The rename (stopped_actors → batch_actors, send_stop_command_acks → send_batch_command_acks) is applied consistently; no stale references to the old names remain elsewhere in the crate.
• Dedup key collection now happens on the raw (pre-dedup) batch and is deduped again by a HashMap inside send_batch_command_acks, so a batch containing both a start and stop for the same actor still acks once at the highest index. Looks correct.
• Ack still doesn't clear processed_command_idx for the newly-included start commands (intentional, the tick handles full re-acks/clearing), so in-process replay suppression is preserved.
• Immediate ack happens right after create_actor(...) schedules the detached actor_inner task, not after actor startup actually completes. That's fine: startup failures are reported independently via EventActorStateUpdate(ActorStateStopped) in actor.rs, not gated on the command ack, so acking early doesn't swallow start failures. This mirrors the already-accepted pattern for stop acks (fire the message, ack immediately, don't wait for completion), so it extends an existing tradeoff rather than introducing a new class of risk.
• Minor note, not a blocker, already covered by the existing TODO on send_command_ack: acking a start before the process has durably done anything means the same narrow crash-before-ack-commits window documented for stops now also applies to starts, with a slightly worse failure mode (actor never actually started vs. an already-stopped actor). Since this is the same documented tradeoff already accepted in this file, flagging for awareness rather than blocking.

Tests

• start_command_is_acked_immediately mirrors the existing stop_command_is_acked_immediately test well: asserts the immediate ack checkpoint and that dedup state is retained afterward. Good coverage of the new behavior.
• No test for a mixed batch (start + stop in the same call), but the per-key dedup logic is simple enough that this is a minor gap, not a real risk.

Style

• Comments read as complete sentences per the repo's CLAUDE.md conventions, no em dashes, no parenthetical fragments.

No blocking issues found.

🤖 Generated with Claude Code