[BUG] 回合被 dispose（配置热重载）时排队消息被静默丢弃，且事件标记 "canceled" 会误导成用户主动取消

[hywo-x]

0. 一句话

我在一个回合运行中安装本地插件（= 改 <profile>/package.json 的 dsh.profile.bundles），约 2.8 秒后正在跑的回合被中止，同时我排队的那条消息无声消失：会话日志里它被移除、只带 outcome: "canceled"，界面上没有任何提示。我当时的判断是"我的消息被取消了"，但实际上我没有取消过——"canceled" 这个词在代码里跟用户操作无关。这条报告的主体是"丢消息"，重载只是触发器。

1. 环境

• DeepSeek Harness 桌面端 0.2.0-rc.2（dsh/package.json → "name": "@deepseek-ai/dsh-desktop-runtime"，"version": "0.2.0-rc.2"，exe FileVersion 同），win32/x64，nodeVersion 24.18.1、pnpmVersion 11.7.0，更新通道 nightly
• profile desktop（DSH_HOME=C:\Users\WINDOWS\.dsh）
• 会话 session-7036c050-c6b0-4833-8446-169ee768345e，工作区 C:\Users\WINDOWS\Documents\deepseek-harness\default-workspace

2. 现象（重点：丢消息）

回合执行中，往 <DSH_HOME>\profiles\desktop\package.json 的 dsh.profile.bundles 末尾追加一项后约 2.8 秒：

1. 回合被中止：turn/end → {"reason":{"kind":"aborted","reason":{"kind":"disposed"}}}；该回合的全部输出从未送达用户（不是发送失败，是这轮结果根本不存在了）；
2. 排队消息被静默丢弃：收件箱里那条被移除，事件只有 {"removedCount":1,"inserted":[],"outcome":"canceled"}，界面没有任何提示；
3. 用户视角 = 「我的排队消息不见了 / 被取消了」。要确认到底发生了什么，只能事后解压会话日志（多帧 zstd）逐事件翻。

3. 复现

1. 让一个回合开始跑（任意耗时回合）；
2. 回合运行期间修改 <DSH_HOME>\profiles\<profile>\package.json 的 dsh.profile.bundles（追加/删除任意一项）；等价操作：在插件页安装/卸载一个插件（GUI 走同一条重载路径，见 §4.4）；
3. 在该回合期间排队发送一条消息；
4. 观察：回合在 2–3 秒后被 abort，排队消息消失且无提示。

4. 代码级因果链

1. @deepseek-ai/dsh-hmr 监听 profile manifest 与两个 profile 级补丁文件：dsh-hmr/lib/index.js:353 const manifestPath = join(profile.dir, "package.json")；:376 await this.watchConfig(manifestPath, () => refresh(true))；chokidar awaitWriteFinish: true（2 s 窗口）+ debounce: 100 正好解释 2.77 s。
2. bundles 变化绕过 :359 的 if (manifestOnly && bundles === lastBundles) return，于 :370 await reconcileProfilePatches(this.ownerContext.root, patches, "dsh")。
3. reconcileProfilePatches（dsh-app-boot/lib/index.js:3468-3495）重算 patch 集合、entry.update(...)，然后 :3488 await Promise.allSettled(previousFibers.map(({ fiber }) => fiber.await())) —— 等待所有旧 fiber 结算；patch 子树重建，归属其中的 agent fiber 被 dispose。
4. GUI 装/卸插件同路：dsh-plugin-manager/lib/index.js:2031-2034 reload() → 同一个 reconcileProfilePatches；change(...)（:2035-2057）在 withFileLock(join(profile.dir,"package.json"), …) 内执行并置 application: hmr !== undefined ? "applied" : "restart-required"（:2042）。
5. 丢消息的直接原因：dispose 触发 owner effect 卸载 → machine.cancel({ kind: "disposed" })（dsh-agent-loop/lib/index.js:1688；dispose 触发点 :1713-1721），而 cancel()（dsh-agent-loop/lib/index.js:815-821）先 inbox.clear() 再 abort——一次 dispose 同时产出「清收件箱」与「abort」，且被丢弃的条目没有任何用户可见的回执。
6. 措辞误导：dsh-agent-loop/lib/index.js:195 const outcome = discardRemoved && actualDeleteCount > 0 ? "canceled" : void 0——只要有条目被丢弃就写 canceled，与「用户点了取消」无关。正常消费走 claim()（discardRemoved: false），因此正常投递的移除事件没有 outcome 字段（本会话实测：#6、[bug] SQLite scanRows torn-tail tolerance deletes valid events together with the bad row #675、[Feature Request] TUI支持 #842、插件写入自定义 session 事件类型会让会话永久无法恢复 #918、[Bug Report] Web UI 弹层：焦点可逃逸出 `aria-modal` 对话框，一次 Escape 同时关闭多层弹层（各弹层独立监听、无 stack 协调） #943 均无 outcome；只有被丢弃的那次 npx @deepseek-ai/dsh web failed with node-pty #835 有）。
7. 排除项：用户主动取消走 agent.cancel({ kind: "user" })（dsh-api-session-controller/lib/index.js:998），日志里会显示 user；本例是 disposed。session/end-seed 属正常事件（dsh-session/lib/index.js:1351-1352）。插件管理器自身没有文件 watcher。

5. 会话日志证据（原始 JSONL）

证据：<DSH_HOME>\sessions\--C-Users-WINDOWS-Documents-deepseek-harness-default-workspace--\session-7036c050-c6b0-4833-8446-169ee768345e\session.v4.jsonl.zstd（多帧 zstd，需 zstd -dc）

序号	时间	事件	内容（节选）
#830	22:25:43.708	tool/call	edit 写 <DSH_HOME>\profiles\desktop\package.json（dsh.profile.bundles 末尾追加插件名）
#835	22:25:46.480	agent/inbox/spliced	{"target":"next-turn","start":0,"removedCount":1,"inserted":[],"outcome":"canceled"} ← 排队消息在此消失
#838	22:25:46.480	turn/end	{"turn":1,"reason":{"kind":"aborted","reason":{"kind":"disposed"}}}
#839	—	session/end-seed	正常事件，与本问题无关

写盘 43.708 → 丢消息/abort 46.480 = 2.77 s。

（该排队消息的原文与三次编辑都在更早的 agent/inbox/spliced 事件里——即内容确实存在于日志中，但从未进入模型上下文，用户界面也无从知晓。）

6. 期望行为（Expected behavior）

• 排队消息不能静默消失：任何非用户主动操作导致的丢弃，都要有可见回执——界面提示 + 一条显式事件（例如「因配置重载，1 条排队消息被丢弃」）；
• 更好的做法是干脆不丢：排队队列跨 abort 保留，恢复后由用户决定重发还是丢弃；
• 事件语义要能区分「用户取消」与「系统丢弃」：outcome: "canceled" 换成不会误导责任方的值；
• 重载择机执行：存在活跃回合或排队消息时，先提示确认或推迟到空闲。

（具体实现建议见 §8。）

7. 已证实 vs 未隔离（诚实标注）

已证实（本机实测 + 代码引用）

• 排队项在回合被中止的同一毫秒被移除，且只带 outcome:"canceled"（§5）；
• cancel() 先 inbox.clear()（dsh-agent-loop/lib/index.js:815-821）；outcome 的判定只看「有没有条目被丢弃」（:195）；
• dsh-hmr 监听 <profile>/package.json（dsh-hmr/lib/index.js:353-376），bundles 变化触发 reconcileProfilePatches（:359、:370），后者 await 所有旧 fiber（dsh-app-boot/lib/index.js:3488）；
• GUI 插件安装/卸载与手改 bundles 走同一重载路径（dsh-plugin-manager/lib/index.js:2031-2057）。

未隔离（推论 / 未能复现）

• 「任意 bundle 列表变化都会 dispose 无关 fiber」——在独立 DSH_HOME 的测试 profile 上用探针插件（ctx.effect 打日志）观察：修改 profile 的 cordis.patch.yml、以及向 bundles 追加一个能实际加载的新 bundle，都没有观察到无关插件 fiber 被 dispose（两次实验里都没有第二个回合在跑）。所以触发条件的精确边界待上游确认；但真实那一次的事件序列、时间戳、reason: disposed 与上述代码路径完全一致。
• 丢消息时前端是否有任何提示（本次实测：没有）。
• 其他平台/版本（darwin、0.2.0-rc.2 之后）的表现。

8. 建议

1. 丢消息至少要可见：inbox.clear() 之前把被丢弃的条目落一条显式事件 + 界面提示（「因配置重载，N 条排队消息被丢弃」），或者让排队队列跨 abort 保留、由用户决定重发；
2. 措辞：outcome: "canceled" 拆成能区分「用户取消」与「系统丢弃」的值（例如 discarded），避免把责任误导到用户；
3. 重载择机：reconcileProfilePatches 前检查是否有活跃回合/排队消息，若有则提示确认或推迟到空闲（插件管理器已有 withFileLock 与 hmr.runExclusive，加一个「回合空闲」条件是自然扩展；与 建议：插件重载与宿主重启——已加载产物身份 / 单插件重载 / 人确认重启 #8470 的方向一致）；
4. 文档：dsh-hmr README 的「已知限制」补一条——profile manifest / 补丁文件变化会重载 patch 子树，可能打断进行中的回合并丢弃排队消息。

9. 相关讨论（发帖时交叉引用）

• 重载打断在途会话：[BUG] Changing cordis.patch.yml while sessions are running kills every running session mid-turn #8857（改 cordis.patch.yml 会杀死在跑回合）、[Bug] Live profile reload leaves session-scoped services unavailable: session/follow fails with gateway/service-unavailable #9100、【Bug】live 重载 profile 补丁后，在途会话工具目录静默塌缩（47 → 14），模型陷入幽灵工具调用循环 #7519、Editing a profile patch layer while DSH is running strips the agent's tools from live sessions #8635、[Bug] Native HMR starts replacement activation before asynchronous disposal finishes #6883
• 排队/待处理消息丢失：Inbox: same pending message canceled + re-inserted after an error turn (429) - duplicate agent/inbox/spliced inserts #9482（pending message canceled + 重复插入，429 错误回合触发）、[Bug] Queued message row disappears between the inbox claim and transcript admission (0.2.1-alpha.1, with a locally verified patch) #9241（claimed 后到 transcript 之间排队行消失，附本地补丁）、[Bug] claimed 的输入在 prepareRequest 抛错时会永久丢失：本机 154 份存档里 14 例 #6964（claimed 输入在 prepareRequest 抛错时永久丢失）、中断之后，排队消息只剩「编辑/删除」：唯一的发送按钮被 running 门挡成灰色 #8018（中断后排队消息只剩编辑/删除）
• 机制诉求：建议：插件重载与宿主重启——已加载产物身份 / 单插件重载 / 人确认重启 #8470（单插件重载 / 人确认重启）、已安装 bundle 的「原地换代」缺少官方入口：连卸载后再挂载都拿不到新模块（附实测） #7526（bundle 原地换代缺官方入口）

本贴与上述的区别：触发面是"配置重载/agent dispose"，被丢的是用户排队消息，并且把 outcome:"canceled" 的误导性语义与 cancel()→inbox.clear() 的代码路径指了出来。

---

[PerryLink]

丢消息这条链路你说对了，但有两处要修正：canceled 是有意的语义、不是误用；而且回执其实已经存在，只是没人接。

链路成立

dispose → packages/core/agent-loop/src/index.ts:564 的 machine.cancel({ kind: 'disposed' })，注意它没传 keepInbox；于是 packages/core/agent-loop/src/agent.ts:175-181 的 cancel() 先 this.inbox.clear() 再 abort。inbox.ts:98-101 的 clear() 走 splice，而 :226 那句 const outcome = discardRemoved && actualDeleteCount > 0 ? 'canceled' as const : undefined 就是你在日志里看到的标记。

对照一下正常领取：inbox.ts:110-111 的 mutate(..., false) 传的是 false，所以正常消费不带 outcome——和你观察到的一致。

修正一：回执已经有，缺的是消费者

inbox.ts:236-237：

if (discardRemoved) { for (const message of removed) this.dispatch.emit('agent/inbox/discarded', { message }) }

每条被丢掉的消息都会发一个实时事件。问题是只有三个地方订阅它：goal-round-driver、subagent 的 manager、user-questions——客户端 UI 一个都没有。客户端只消费 agent/inbox/spliced（packages/client/ui-chat/src/client/conversation-nodes/inbox.ts:119），而它在 :87 还专门按 splice.outcome !== 'canceled' 做了分支。

所以正确的说法不是"没有任何回执"，而是"事件发了，UI 没接"。诉求也就更清楚了：让客户端订阅 agent/inbox/discarded 并给一个可见提示。这比"请发明一个回执机制"好提得多，因为东西已经在了。

修正二：canceled 是有意的

两份 README 都写明了：packages/core/agent/README.md:91 → "Ordinary removals and clear() are durable cancellations."；packages/core/agent-loop/README.md:71 → "Ordinary removals carry outcome: 'canceled' and emit agent/inbox/discarded { message }"。

所以改这个值会连带改客户端分支和测试，代价不小。更稳的做法是加一个来源字段（比如把 cause 一起带上），而不是动 canceled 本身——你要解决的其实是"分不清是谁取消的"，不是"这个值错了"。

还有一点：范围比你想的窄

packages/api/session-controller/src/commands.ts:509 → agent.cancel({ kind: 'user' }, { keepInbox: true })。也就是说用户主动停止这条路径已经会保留队列了，丢队列现在只发生在 dispose 这类取消上。你的症状是真的，但"用户自己停也会丢"已经不成立。

顺带说，CancelOptions.keepInbox 就是为这个加的（packages/core/agent/src/runtime-types.ts:38-45，注释写的是 "Preserve queued and steering inbox items instead of discarding them… and no canceled inbox splice is logged"）。所以最自然的修法是给 dispose 那条路径也传 keepInbox: true，或者至少在清空之前发一条用户可见的通知——两条都比改语义小。

热重载链路我核过了

和你描述的一致：packages/boot/hmr/src/index.ts:384（manifest 路径）、:390、:407 的 watchConfig，配 packages/boot/app-boot/src/index.ts:396 的 Promise.allSettled(previousFibers.map(...))；插件管理器走同一条路（plugin-manager/src/index.ts:852 的 hmr.runExclusive）。装插件和手改 bundles 都会触发，所以这个缺陷不只出现在改配置的时候。

边界

我核的是 origin/master = 571902028a（2026-10-14）。你帖里的行号是 0.2.0-rc.2 的编译产物行号，源码位置和它们不同，上面给的都是源码行。另外你引的几处（:815-821、:1688、:195、:2031-2057、:3488）对应的源码我也重新定位了，若你要投稿建议一并换掉。

[Edison-A-N]

+1