Repository navigation
Steer is broken three ways on busy sessions: silent queue downgrade, abort-and-strand, restored-queue stall (v1.22.1/1.22.2) #3370
Description
OpenChamber version
1.22.1 and 1.22.2 (reproduced on both; two independent machines, different settings)
Defect 1 — explicit Steer silently downgraded to a queue delivery
packages/ui/src/components/chat/ChatInput.tsx, in handleSubmit:
const [deniedPermissions, dismissedQuestions] = await Promise.all([
sessionActions.dismissOpenPermissionsForSession(currentSessionId),
sessionActions.dismissOpenQuestionsForSession(currentSessionId),
]);
if (deniedPermissions || dismissedQuestions) {
void handleQueueMessage();
return;
}The queue fallback ignores delivery === 'steer'. Stale permission/question rows in the client stores (e.g. permissions replied out-of-band, so the client never saw permission.replied) make the dismiss calls return true on ordinary sends, so every Steer on an affected session becomes a server-queue delivery instead. Observable: the message later re-enters the chat via the queue dispatch while the queue block is still rendered — reads as sent twice; or pops in minutes later at run end. Fresh sessions (no blocker history) steer correctly, which confirms the trigger. Suggested fix: when delivery === 'steer', dismiss the blockers but send directly (prompt_async with delivery: "steer"); keep the queue fallback for Queue-mode and non-steer sends. Branch with tested fix available: fix/steer-v1.22.2 — happy to open a PR.
Evidence (single Enter press, 1.22.1): t+0.0s POST /api/message-queue/.../items (rev bump, queue block renders) instead of a send; t+1.1s the dispatch tick delivers it as a fresh user message.
Defect 2 — steer into a tool-executing turn aborts it and strands the prompt
Same model both sides (mimo-v2.5), direct sends, no queue involved:
- Steer at +10s while a bash tool is executing: in-flight run aborted (
MessageAbortedErrorcard) and the steered message is never answered — the session dead-ends (user message, no assistant reply, no new run). - Steer at +7s during the reasoning phase: merged cleanly, run continued, answered.
So a prompt steered into a tool-executing turn kills the turn and drops the new prompt on the floor. At minimum the steered prompt must start its turn; ideally the abort card should not read as an error when it is the steer doing the interrupting.
Defect 3 — restored queue item never dispatches on 1.22.2
An item queued pre-restart is restored at boot ([message-queue] restored queues for 1 session(s)) then sits ~45 min on an outwardly idle session (no part updates, dispatcher log silent — no sends, no errors). Expected: the boot-time reconcile tick delivers it once the session is idle.
Workaround
Follow-up behavior Queue, or Stop-then-send. Avoid Steer on 1.22.x for now.
Activity
openchamber-bot commentedon Sep 5, 2026
For the maintainer: PR #3369 by the same reporter already covers defect 1. Defects 2 and 3 need separate investigation.
Defect 1 — queue downgrade. The blocking-prompt branch at
ChatInput.tsx:1370-1387ignoresdelivery === "steer"when it queues after dismissing stale permissions/questions. PR #3369 fixes this correctly: steer clears blockers then sends directly viaprompt_asyncwithdelivery: "steer". Merge-ready once reviewed.Defect 2 — steer aborts tool-executing turn. Steer during a tool phase (e.g. bash execution) hits the runner abort path:
session.abort()terminates the in-flight run, surfacing aMessageAbortedErrorcard. The steered message is never dispatched as the next turn — it lands in the chat with no assistant reply. Steer during reasoning merges cleanly because the runner accepts the new content without aborting. Root cause is plausible but unconfirmed for the reporters exact symptom: the runner discards the steered message when the run state transitions to aborted beforeprompt_asyncwithdelivery: "steer"can establish a new turn. This overlaps with #2221 (abort-while-queued stalls) and #3194 (message dropped during busy session), but is a distinct path — steer goes throughprompt_async, not the queue dispatcher. Needs upstream input on whether steer should queue the prompt as the next turn rather than aborting, or whether the runner should handle steer-during-tool differently.Defect 3 — restored queue stall. The server-side dispatcher at
runtime.js:589-593arms dispatch for each restored queue viareconcileAll()afterload(), which callsarmDispatch(sessionId, 500ms). Thetick()then callsisSessionIdle()which hits/session/statusand/session/{id}/message. If the session is already idle at boot, the tick should fire within ~500ms and send. The reporter observes 45 minutes of silence on an idle session, which points to either: (a) theisSessionIdlemessage tail check returning an unfinished assistant message from a prior run that the session status API does not mark busy, or (b) a race where the restore loads butqueues.size === 0before the write settles. Either way, the server-side queue dispatcher is the right code path — need logs from a failed restore to narrow further.Reproduction approach for defect 2
Steer a prompt during tool execution (not reasoning) on a session with follow-up behavior set to Steer. The abort card appears and the steered message sits unanswered. Reproducing defect 3 requires queuing a message, restarting the server, and checking the dispatcher log for the restored session after boot.
JustinKeltner commentedon Sep 5, 2026
Concrete transcript for defect 2 (abort-and-strand)
Session "Delayed hi after 60 seconds", OpenChamber 1.22.2, mimo-v2.5, steer submitted as a follow-up on a busy run. Delivered directly — no queue item ever existed for this session.
sleep 60 && echo "hi"(no output)+User aborted the commandContrast from an identical setup 18 minutes later (same model, same sleep tool): steering 5s into the sleep merged cleanly, the sleep finished, and the reply came back. So the same steer-into-active-turn path folds the prompt sometimes and aborts-then-strands it other times.
JustinKeltner commentedon Sep 5, 2026
Defect 2 — third data point: merges mid-MCP-tool on stock 1.22.2
Same racy steer-into-active-tool path, different outcome again — this time on a toolport (MCP) call, on unmodified 1.22.2 (fix branches not deployed):
Session "Proxmap -32001 timeout root cause (fork #1)":
toolport_toolport_call_toolexecutingSample set across today's tests, same code path:
So the abort-vs-merge outcome is not tool-type-deterministic (bash produced both) and is present on the latest release. Looks like a race between the steered
prompt_asyncand the runner's step boundary.JustinKeltner commentedon Sep 7, 2026
Here's a Loom video of the issue on desktop (happens on all platforms since I think 1.22.1) - https://www.loom.com/share/ab9d39cb126342b3a0873d0a8b58695e
JustinKeltner commentedon Sep 9, 2026
Retested 2026-09-09 on a three-role 77042 fleet, all official 1.22.2: queue path healthy (explicit Queue-mode follow-up lands server-side, no toast, run-end flush, single delivery). The downgrade branch is still present in the shipped 1.22.2 bundle — matches the filed code reading; no live Steer-mode sample this round (setting was Queue). No change to the defect-1 claim; #3369 still covers it and is mergeable.
JustinKeltner commentedon Sep 9, 2026
Race extended same day, direct prompt_async steers mid-sleep 180: +48s merge, +69s merge, both answered post-tool. Tally abort 1 / merge 4. No upstream change in the path. Step-boundary race stands — a clean steer-into-tool is consistent with the bug, not evidence against it.
fix(chat): preserve explicit steer after dismissing blockers (#3369)
btriapitsyn commentedon Sep 19, 2026
Could you retest defect 2 on the latest version? We tried sending a Steer follow-up while a foreground subagent was running, and again while a bash tool was running sleep 60. Both completed normally and the follow-up was answered. We haven't reproduced the abort-and-strand behavior in those attempts. If it still happens for you, please share your OpenChamber and OpenCode versions and a fresh recording or transcript. Thanks!
openchamber-bot commentedon Oct 18, 2026
This issue has been automatically marked as stale because it has not had any activity in the last 28 days. It will be closed in 7 days if no further activity occurs.
yulia-ivashko commentedon Oct 18, 2026
Thanks for the thorough report. Defect 1 (Steer silently turned into a queued message) is fixed in #3369 and defect 3 (a restored queue that stalls) in #3371, both released since. We couldn't reproduce defect 2 (abort and strand) on the current version, so we're closing this. If Steer still aborts and leaves the message stranded on the latest version, leave a comment here and we'll reopen it.