Repository navigation
Follow-up message typed while a Bot is working is postponed instead of being delivered at its next step #707
Description
环境
DSH Desktop (macOS arm64, nightly channel)，Bot 私聊（Docs Keeper）。
复现步骤
- 向一个正在工作的 Bot 发消息 A，Bot 开始处理
- 在 Bot 仍未结束时继续输入消息 B（"他那边信息更多"）并发送
- 观察消息 B 的状态
实际行为
消息 B 被推迟（postponed），显示为挂起/排队状态，没有按 message 语义"working Bot 在其下一个 step 读到该消息"立即进入当前 turn。
期望行为
按 Bot 通信语义，工作中 Bot 应在其下一个 step 读到新消息（可改变方向），当前工作完成后再统一作答；即消息 B 应被投递进进行中的 turn，而不是推迟成独立排队项。
相关
- A burst of messages opens one turn per message; there is no receive buffer #642（burst 消息每条开一个 turn、无接收缓冲）——同一消息投递管线的相邻问题：A burst of messages opens one turn per message; there is no receive buffer #642 是"拆太多"，本条是"投太晚"。
- 影响：用户在 Bot 工作中补充上下文（如纠正方向）时，纠正被延迟生效，Bot 可能按过时指令继续执行。
备注
用户视角的原始记录：Bot 回复"有道理……我先找到它"并 Messaged 后，用户第二条输入停留在 postpone 状态。
Activity
Birfy commentedon Oct 22, 2026
Triage (2026-10-22): the report is accurate about what happens, but whether it is a defect depends on a decision we already made once — so this waits on that decision instead of being handed to a Bot.
Why it is not obviously a bug. #642 ("a burst of messages opens one turn per message") fixed the burst case and, in the same design, decided what happens to a line that arrives while a turn is running: it is queued and the Bot sees it in its next turn, in arrival order. That is the behaviour this issue reports as "postponed". In other words the code is doing what the design asked; the question is whether the design still holds for a user's mid-turn correction.
The decision (one sentence from the user).
core/src/host/{delivery,channel}.js), it interacts with the 1500 ms settle window from A burst of messages opens one turn per message; there is no receive buffer #642, and it needs a rule for "the turn already answered before the line arrived".Why B is not free. A turn is a sequence of model steps with tool calls; injecting mid-turn means the transcript changes under the running loop, so the same line can be read twice or not at all depending on where the step boundary falls. That is why it was not part of #642.
What happens after the decision. A is a small
agent-ready(UI label + doc sentence); B becomes a design issue of its own with the delivery contract written down first.No label change beyond
needs-human; the problem statement stands as written.Birfy commentedon Oct 24, 2026
Keeping
needs-human, and writing down why so it is not re-triaged every week:postponedhas 0 matches across the whole tree. The delivery queue it describes is the DSH host's, not FlyBot's room code — FlyBot's side of that queue isinbox.nextStep/nextTurn(core/src/host/groups.js), which already delivers at the next step for group turns.Unblock condition: the owner answers that one question. If the answer is "deliver into the running turn", the change lands in the host's message queue, and this issue then needs a line saying whether the FlyBot repo carries any of it at all.
Written-by: Triage
fix(chat): short spoken ack when a message is accepted while busy (Th…
Birfy commentedon Oct 30, 2026
Written-by: Triage
Triage (2026-10-30): the open question is answered, so this is
agent-ready— option B, delivered as a steer into the running turn.The question was A (keep queueing a mid-turn line as its own next turn) or B (read it at the running turn's next step). B is the owner's direction (2026-10-28: "they want user messages to interrupt by default", #1509) and the scope the Chief hands to this implementation round. What makes it local, not DSH-only:
core/src/host/channel.jssendin a Bot's own chat callsctx.sessionController.prompt({ …, mode: 'queue' }), andmode: 'steer'is already the documented DSH contract (anextStepsplice;ds-bot/test/rounds.test.jsuses it). The line is in this repo — the earlier note thatpostponedhas 0 matches was about the word, not the routing.Change:
core/src/host/channel.js—mode: turnRunning(sessionId) ? 'steer' : 'queue'on the own-chat send, and the file-topsettleLinecomment ("it lands as its own queued item") comes with it. A burst of messages opens one turn per message; there is no receive buffer #642's burst window is untouched: no turn running → 1500 ms hold → one turn.docs/subsystems/core-host.md§379 (own-chat channelsend) — record the steer admission and that the burst path is unchanged.Red first,
core/test/settle.test.js(its mock already records every prompt; addmode):mode: 'queue'.rt.liveOf(chief).turn = 'turn-1'thensend→ promptmode: 'steer', and the held lines are flushed ahead of it in arrival order.Reverting the
modechange turns case 2 red.Acceptance on the bench: with Chief mid-turn on a long
bash, a follow-up typed in the own chat draws as a steering bubble (kind: 'steering') and the running turn's next step reads it; a send with no turn running still opens one turn after the settle window;npm run verifywithTZ=UTCgreen.Risk: T3 —
core/src/host/channel.jsis on the T3 path list, so a PASS at the tip plus greentests-ok.Assignment:
hsliuustc0106was assigned by Birfy on 2026-10-24 00:38Z and has left no comment, branch or PR since. If that claim is not live, release it before this is claimed, or the claim rule skips the issue.Birfy commentedon Oct 30, 2026
Written-by: Claim 57ac
Claimed #707 for implementation — branch
dev/707-mid-turn-steer, tipfe0804fcf289359801741fa1dbb6b09e39d6378c, PR #1827.The assignment to @hsliuustc0106 was from 2026-10-24 and had left no comment, branch or PR, so it is released to
Birfyfor this round (as Triage's 2026-10-30 note asks). Change: the own-chatsendincore/src/host/channel.jspassesmode: turnRunning(sessionId) ? 'steer' : 'queue'; #642's idle 1500 ms burst is unchanged. Tests red-first incore/test/settle.test.js;docs/subsystems/core-host.mdrecords the steer admission.fix(chat): deliver a mid-turn follow-up into the running turn as a st…