cancel() 把 turn/end 写成 reason:null（违反 TurnEndReasonMap 协议）—— 客户端事件订阅者永久死亡，对话区全空白

[seeyouagain-laoda]

问题：程序化 cancel() 把 turn/end 持久化为 reason: null（违反协议），导致客户端事件订阅者永久死亡、对话区全空白

环境

• DSH 版本：0.2.0-rc.2（Windows x64 桌面版）；0.2.1-alpha.1（dsh web）同样复现
• 操作系统：Windows 11 x64
• 触发方式：客户端插件在回合运行中调用程序化 session.cancel(reason, { keepInbox })

摘要

通过程序化 cancel() API 停止一个运行中的回合时，落盘的 turn/end 事件的 data.reason 被写成 null。这违反了文档中 TurnEndReasonMap 的协议约定（取消中断应产生 { kind: "aborted", reason: <AgentCancelCause> }）。随后 Web/桌面客户端的事件流订阅者（event feed subscriber）读到该事件即抛异常，整个事件流的订阅者全局死亡——所有会话的对话视图全部空白，直到重启应用或刷新页面。轨迹（Trajectory）视图不受影响，因为它不读取 reason 字段，所以表现为「轨迹正常、对话空白」，非常具有迷惑性。

复现步骤

1. 启动一个正在执行工具调用的回合
2. 由插件调用 controlTarget.cancel("some-reason", { keepInbox: true })，随后 steer(...)（重规划模式）
3. 检查会话日志（~/.dsh/sessions/<工作区>/session-*/session.v4.jsonl.zstd）

真实会话中实际落盘的事件（seq 1030）：

{"type": "turn/end", "seq": 1030, "time": 1791299223721, "data": {"turn": 3, "reason": null}}

客户端表现

打开该会话后，浏览器控制台：

[session-controller] event feed subscriber failed:
  TypeError: Cannot read properties of null (reading 'kind')
    at Object.start (…/plugins/??@deepseek-ai/dsh-client-ui-open-in-app/client.js,…)
Error: Minified React error #130
slot entry crashed in 'conversation.composer.dock'

• 对话视图：完全空白（无消息、无输入框）
• 之后切换到任何其他会话也都是空白（订阅者已全局死亡），直到重启
• 轨迹视图仍能正常渲染（不读取 reason）

期望行为

按 docs/subsystems/session 与 python/sdk/README.md 的约定：

• turn/end 必须携带字符串类型的 data.reason.kind —— 官方 Python SDK 对缺失 kind 的事件直接抛 SdkProtocolError: "turn/end event requires a string data.reason.kind"
• 取消请求导致的中断应持久化为 { "kind": "aborted", "reason": <AgentCancelCause> }

实际行为

reason 被持久化为 null。Python SDK 会按协议违规拒收这份日志；JS 客户端则直接在它上面崩溃。

修复建议

在 turn-end 序列化路径上，把程序化 cancel 的原因映射为结构化的 TurnEndReason（例如 { kind: "aborted", reason: <cause> }；拿不到 cause 时回退 { kind: "interrupted" }）。另外建议加固客户端组装器：遇到畸形的 turn/end 事件时跳过或降级处理，而不是让整个事件流订阅者崩溃。

临时规避方案

对会话日志做「帧感知」的定点修复（把 reason: null 改写为 {"kind": "completed"} / {"kind": "interrupted"}，保持 zstd 帧结构与 seq 连续性不变），即可恢复受影响的会话。

---

补充说明：触发源是一个桌宠插件的重规划控制（cancel + steer）。插件侧调用的是公开 API，用法本身符合文档；缺陷在 DSH 写入侧的序列化。

[Kanadego]

补一条写入侧的定位。

先说结论：日志里那行 reason: null 不是数据损坏，是 DSH 在「取消一个正在执行的回合」时自己写进去的。我按包内源码追了一遍，写出它的过程大概是这样（0.2.0-rc.2 / Windows）：

1. 取消的入口不检查原因。cancel(cause) 把传进来的 cause 原样交给 AbortController，不做任何校验 —— 传字符串、传一个它不认识的 kind、甚至什么都不传，都能一路走到后面。
2. 回合被打断后，catch 里会先把「取消原因」翻译成 turn/end 需要的结构。
3. 但那个翻译函数只认识四种原因：user / parent / disposed / hook。遇到不认识的值，它不兜底，而是直接抛错。
4. 抛错的位置很要命：它在 catch 块里，而「这一轮该怎么结束」的那个变量，本该在紧接着的两行被赋值。异常一抛出，赋值就没发生，变量还停在初始的 null。
5. 最后的 finally 不检查这个变量，照原样写进日志。

所以只要有人用「它不认识的 cause」调一次程序化 cancel，日志里就会多一条 reason: null；那四种合法原因不会。

具体位置：

• dsh-agent-loop/lib/index.js:815-821 —— 取消入口，对 cause 不做校验
• 同文件 :1009 → :731-745 —— 翻译函数，:743 是抛错那行
• 同文件 :948（变量初始为 null）、:1025-1033（finally 无条件落盘）
• dsh-util-values/lib/index.js:9-12 —— 那个「不可能到达」断言其实是抛异常的

顺手一个建议：翻译函数碰到不认识的值时，退回 {"kind":"interrupted"} 就行。抛错在这里没有收益 —— 它既没告诉调用方，也没保住这条日志，反倒把日志写坏了。

客户端侧再补一句：#9156 说的是 chat 包里的三处，但装配器那条路上还有一个共用定义同样没做保护，在 dsh-client-ui-trajectory（lib/client.js:988-1005）；chat 包里除此之外还有几处同样的写法。所以「轨迹正常、对话空白」只是渲染路径的差别，不是它安全 —— 坏事件在装配阶段就被撞上了。

规避我按帖子里说的做了：帧感知定点修复（只重压含坏行的那一帧、保持 seq 连续）+ 客户端空值保护，没有重启应用就恢复了。