fix(server): a message promoted into a stopping run stays queued

[lbgos]

Problem

A queued message promoted to Steer after Stop was accepted could be moved onto the stopping run and lost. The run can still report running while its provider finishes stopping, so checking status alone was insufficient.

Change

Use the persisted Stop marker in the shared steering path to reject explicit steer, restart and queued-message promotion into a stopping run. Rejection leaves the queued message and its held state intact.

A normal send whose automatic delivery would steer that stopping run instead takes the existing queue path. It follows earlier queued messages and, consistent with current main, resumes their hold. An explicit Steer/Restart still fails during the Stop window. Ordinary interrupt-and-restart steering without an explicit Stop is unaffected.

Scope and approval

Maintainer takeover of lbgos's contribution, preserving contributor history. Shared server orchestration covers clients and providers using these commands. This integrates #21473's user-send-resumes-queue behavior; agent, MCP and scheduled sends retain their existing exclusions. No merge is requested.

Verification

At 84e64d8, incorporating main c274a25:

• 235 focused orchestration tests passed, plus scoped server typecheck, formatting and lint. Only pre-existing lint warnings remain. Fresh independent full Opus and Sol reviews were clean; their independent focused runs passed 61 and 49 tests respectively.
• The existing promotion regression proves rejection preserves the held queue. The normal-send regression proves ordered queuing without steering and release of the hold. The old held-queue expectation failed after current-main integration and was corrected to match the intended resume behavior.
• Independent scratch proof drove the real orchestrator, effect worker and projection store: after a controlled provider-stop event, the earlier queued message reached starting and the normal send remained behind it, with no held runs or steering. Without the normal send, the queue stayed held. Replacing the orchestrator with the base version reproduced the lost-send failure. The test waited on domain events, with no wall-clock sleeps.

Limits: deterministic service proof with a controlled Codex-shaped adapter and injected terminal events, not a live provider or browser/native Resume flow. The scratch proof stops at the next run reaching starting; it does not claim that run completed a provider turn. Review also confirmed Stop disposes the delegated-completion cohort before delivery, so the previously suspected retry concern does not require an extra guard.

Current-head CI remains separate from the focused local checks.

Prepared through T3 Code: Claude Opus 5.5 tests and independent review, Claude Fable 5.1 implementation, and GPT-6.1 Sol independent review, using Claude Code and Codex harnesses.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: 65996d0d-6039-4fde-b58a-876508413bd8

📥 Commits

Reviewing files that changed from the base of the PR and between c71f5af and 42a849d.

📒 Files selected for processing: 2

• apps/server/src/orchestration-v2/Orchestrator.ts
• apps/server/src/orchestration-v2/SteeringCompletion.integration.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.

📝 Walkthrough

When Stop has reached a target run, the orchestrator rejects steering into that run. It also changes automatic steering or restart delivery to queueing. Integration tests check both behaviors while the queue is held.

Changes: Delivery after stop request

Layer / File(s)	Summary
Stop guard and queue fallback apps/server/src/orchestration-v2/Orchestrator.ts, apps/server/src/orchestration-v2/SteeringCompletion.integration.test.ts	dispatchSteerIntoRun rejects steering when Stop has reached the target run. dispatchMessage changes automatic steer_active and restart_active intents to queue_after_active in that state. Integration tests check that queued messages remain held and in order.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 42a84

The reviewed Stop-aware delivery change is mergeable after normal checks; no unresolved defect was identified.

Security architecture risk: 🔵 Low · up to 42a84

The change preserves accepted Stop decisions and keeps later messages queued instead of sending them into work that is shutting down. No new privileges or external interfaces are introduced. Remaining uncertainty concerns interruption and recovery behavior.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed decision affects the targeted run and its thread queue through the shared dispatch path. It changes when existing message content reaches an existing provider path; the production diff adds no new external destination, credential use, or privilege grant.

Trust Boundaries and Controls

• observed — The new routing decision stays inside existing dispatch enforcement. Explicit steer and restart modes reach the shared Stop guard, while queued delivery still checks provider queue capabilities. No new identity or authorization transition is introduced by these changed blocks.

Resilience and Maintainability Implications

• observed — Accepted commands use the existing transaction to reserve a command receipt, append events, apply projections, and enqueue effects before publication. Repeated command IDs return the existing result. Planning failures take the rejected-receipt path rather than committing the planned message transition, supporting failure containment for rejected promotion and queued fallback.

Pre-merge checks: 4

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title uses the conventional commit format and clearly identifies the main fix: messages promoted into a stopping run remain queued.
Description check		The description includes all required sections. It explains the problem, the implementation, scope and approval context, focused verification, test results, limitations, and tooling used.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved at 84e64d8

Macroscope's review found this PR approvable — This is a narrowly scoped orchestration bug fix that handles a Stop/steering race and preserves queued messages, with focused integration coverage. The production impact is confined to the affected dispatch window, with no schema, infrastructure, security, billing, or default-setting changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[juliusmarminge]

Taking over this one. I’ll reduce the tests to the useful coverage, update the implementation against current main, and verify it before publishing the changes.

Dismissing prior approval to re-evaluate 42a849d

Dismissing prior approval to re-evaluate 84e64d8