[Bug] Queued message row disappears between the inbox claim and transcript admission (0.2.1-alpha.1, with a locally verified patch)

[KouzakiUmi]

TL;DR

排队发送的消息会在 Host 把它从 inbox.next-turn 领取（claim）的那一刻从界面上消失，直到下一个 step 开始、持久 user/message 追加进 transcript 才重新出现。QueueDock Steer 必现；普通 claim 在步骤边界出现。实测窗口约 78 ms 起，上限取决于步骤边界何时到来。

• 影响版本：0.2.1-alpha.1（本机 master，桌面壳 dsh-desktop-next 2.0.17-next，Windows）。
• 涉及包：@deepseek-ai/dsh-api-session-controller（客户端提交回显的生命周期）、@deepseek-ai/dsh-client-ui-conversation（QueueDock 队列条）。
• 不涉及：持久化格式、事件类型、模型输入、Host 队列语义。
• 本地已实现补丁并通过测试（分支链接见文末）。按 CONTRIBUTING.md，外部 PR 目前不被接受，所以以 Discussion 形式报告；如政策变化，我可以随时转成 PR。

用户侧体验

先说这个，因为它是问题真正贵的地方：不崩、不报错、可恢复，但会持续消耗"界面所见即真实"的信任。

1. 发送时：agent 正在输出，我不想打断它，于是用队列发送。消息出现即视为收据——我没有读任何状态文案，界面本身就是确认。
2. 消失的一刻：在我没有做任何操作的时刻，那两条文本突然不见了。不是变灰、不是标成失败、不是折叠，就是没有了。失败时有明确样式，成功时反而什么都没有，于是没有任何可判别的信号。
3. 随之而来的自我怀疑：第一反应是"我是不是误触了什么"，第二是"是不是没发出去"。而这时 agent 还在跑，队列里看不到它，对话里也没有——我无法核实。
4. 由此分叉的行为，代价都不小：
   • 重发一遍 → 等 agent 处理时同一段文字可能出现两次（污染上下文、浪费 token、让模型以为我改了主意）；
   • 怀疑客户端或连接坏了 → 刷新、重启，甚至为了"保护现场"中止正在跑的长任务，而那一刻会话其实是健康的；
   • 什么都不做，但一直盯着界面确认（长任务里注意力被占用）；
   • 下次不再用队列，等 agent 停下再说——等于放弃 queue 的设计场景。
5. 恢复时并不真正安心：文本在 agent 开始处理时"又回来了"，但留下的结论是"这个面板关于是否已交付的信号不可靠"。之后队列条一有变化就会紧张一下。

一句话：一条消息曾经显示、然后消失、之后又出现——中间那段时间用户无法判断它的真实状态，界面也不给可判别的信号。

复现

1. 发一条提示词，让 agent 跑起来。
2. 在它运行期间，用队列方式（Enter）发 1–2 条消息。
3. 按 Ctrl/Cmd+Enter 触发 Steer，或等步骤边界自动领取。

证据：一次真实会话的事件时间线

来自本机会话日志（session.v4.jsonl.zstd，多帧 zstd；时间为会话开始的毫秒数）：

time	seq	event
362112	111	agent/inbox/spliced target=next-turn inserted=[排队的消息]
363607	116	agent/inbox/spliced target=next-turn removedCount: 1, outcome: "canceled"
363607	117	agent/inbox/spliced target=next-step inserted=[同一条消息]
363658	120	agent/inbox/spliced target=next-step removedCount: 1（claim）
363685	122	user/message 追加进 transcript

seq 116 到 seq 122 之间，这条消息没有任何渲染归属。

技术定位

三个阶段、三个来源，交接处出现真空：

阶段	期望由谁渲染	实际情况
(a) 进入 next-turn	QueueDock 的 Host 行	正常；本地回显按 rpcId 去重
(b) 被 claim	——	回显早已退休、Host 行已移除 → 无人渲染
(c) 持久 user/message 入档	Chat 的持久节点	正常，但只在 step 开始之后才发生

三处代码：

1. packages/api/session-controller/src/client/sessions/session.ts：observeSubmissionMessage(..., admitted=false) 在 Inbox 接受后一个动画帧就退休 queued 回显，默认此后由 Host 行接管；observeSubmissionInsertions 跳过 queued 结算，因此 claim 不更新它的 receipt。
2. packages/client/ui-conversation/src/client/queue/QueueDock.tsx：queue 只读 inbox['next-turn']，rowCount === 0 时整块返回 null。
3. packages/client/ui-chat/src/client/chat/ChatView.tsx：对话内只融合 placement !== 'queued' 的本地回显，queued 回显不参与，因此也不兜底。

QueueDock Steer 让 (b) 成为确定事件：它在同一次通知里取消 next-turn 行，并把同一条消息提升到 next-step。

影响范围、边界与取舍

场景	结果	说明
排队发送（placement: queued）	受影响	本文修复对象
直接发送（agent 空闲，transcript）	不受影响	回显本就保留到入档
Steer 提升期间	双属主	队列条画回显，Chat 同时把它作为待处理输入渲染
删除排队项 / 取消清空队列	需立即退休	与 Steer 携带同一个 outcome: "canceled"，必须由客户端区分"我请求的是哪一种"
会话销毁（dispose）	已接受的应结算为 observed	否则 composer 会为队列仍持有的消息还原草稿
重连落在 claim 与入档之间	仍可能短暂缺行	README 已声明的既有局限（Chat 位置同样适用）
入档后一帧	队列条可能多显示一行	QueueDock 缺少按 rpcId 的 transcript 去重（Chat 有）

影响面仅限客户端内存态的回显：不改事件、不改持久化、不改 Host 队列语义、不引入新的模型可见输入。

修复参考（本地已实现并验证）

分支（单个 commit）：master...KouzakiUmi:deepseek-harness:fix/queued-echo-claim-handoff

1. queued 结算同样记录 Inbox receipt → claim 会把 receipt 标为 index: null，入档交接照既有规则等待 Inbox 水位；
2. updateQueue 记录 Steer 请求的关联 id，canceled 分支据此区分"提升"与"拒绝"——未请求提升的取消立即按 failed 退休回显，不留幽灵行；
3. observeSubmissionMessage 不再因 Inbox 观察而退休：退休来源只剩入档、拒绝，以及既有的 turn/end 兜底；
4. dispose 对已受理（带 receipt）的回显按 observed 结算，只有 Host 从未受理的才按 failed；
5. QueueDock 的未入档回显过滤把 next-step 的用户行也视为已受理：提升期间让位于 Chat，claim 清空 next-step 后重新持有。

补丁经过一次独立审查（异源模型），审查指出第一版会把"删除排队项"变成幽灵回显、并改变 dispose 的结算语义——这两点已在第 2、4 条修正。

验证

• pnpm exec vitest run packages/api/session-controller packages/client/ui-conversation packages/client/ui-chat → 2190 passed, 1 failed；唯一失败是 media-references.host.spec.ts 的 symlink() EPERM（本机 Windows 权限限制，与改动无关）。
• 定向用例（两个文件）→ 70 passed。
• pnpm run typecheck、pnpm run lint:contracts-ready → 通过。
• pnpm run doc-sync → 40/42 通过，两个失败均为同一 symlink 环境限制。
• 新增回归测试：keeps a queued echo through acceptance and claim until transcript admission、keeps a steered queued echo visible after its next-turn row is canceled、retires a canceled queued echo the client never asked to promote、settles an accepted queued echo as observed when disposed before admission，以及 QueueDock 的"提升期间让位"用例。
• 决策记录：.agents/notes/implemented/bug-fix/2026-10-09-queued-echo-claim-handoff.md。

结语

写这份报告只是希望排队这个能力在长任务里可以放心使用——现在的行为会让人不敢依赖它。如果维护者认为该用别的方案（例如让 Host 在 claim 的同时追加持久消息，从源头消除窗口），我完全接受；这里的补丁只是本地已验证的一种实现。