Bug: turn 收尾阶段对 undefined 调用 .filter()，模型完整答案后本轮被判失败（0.1.2-alpha.5, web 会话）

[liupengf12]

现象

模型已完整产出无任何 tool-call 的 [reasoning, text] 最终答案并成功写盘（assistant/message），随后 turn/end 记录 reason = {kind:'error', error:{message:"Cannot read properties of undefined (reading 'filter')", code:'UNKNOWN'}}。UI 表现为「回答已完成，但本轮被标记运行失败」，答案内容与落盘不受影响。

环境

• 版本：@deepseek-ai/dsh 0.1.2-alpha.5（web 会话，dsh-remote-web-ui；profile bundles = dsh-base + dsh-web-app + dsh-mnemon + @openviking/dsh-memory-plugin）
• 模型：deepseek-v4-flash-vision-exp（provider deepseek-official）
• hasIssuesEnabled 在本仓库为 false，故按 README 指引经 Discussions 上报。

证据（事件序列）

assistant/message  (content=[reasoning,text])   ← 最终答案已写入
step/end
turn/end  ERROR  {message:"Cannot read properties of undefined (reading 'filter')", code:'UNKNOWN'}

code:'UNKNOWN' 只可能由 agent-loop turn() 的 catch 对非 LlmError 的 errorChain(error) 拍平产生（dsh-agent-loop/lib/index.js 约 577–585 行），因此是 turn 收尾真实抛出的 TypeError，与业务代码无关。

根因定位（已收敛）

1. 错误仅在**最后一个无 tool-call 的 step（收尾型最终答案）**出现：toolCalls.length===0 → 返回 completed，turn 走 step/end → agent/turn-stopping 串行下发 → turn/end。除该下发外，step/end→turn/end 之间无其它同步代码。
2. web bundle 里 agent/turn-stopping 的唯一监听者是 dsh-mnemon 的 MnemonAgentLifecycle.scheduleIdleReview（.../web/node_modules/dsh-mnemon/lib/index.js，agent/turn-stopping → scheduleIdleReview(turn)）。这是 web 会话独有、CLI/headless 没有的组件。

已否定（上一版结论的重要修正）

• 不是 message.content.filter：agent.ts:430（runtime lib:690）与 llm-deepseek/pi-ai 的 serializeMessages/context.ts。验证两失败会话的全部派生消息 content 均为数组，且 BlockAssembler.blocks() 经 assembled() 对 envelope.blocks 有守卫、必返数组。
• compaction（eventDelta 的 content.filter）未加载；dsh-hooks-codex / dsh-hooks-claude-code 未加载；dsh-session.foldSurface、assembler 均已守卫。
• dsh-mnemon 同步路径（completedToolActivity / reviewActivity / scoreReviewActivity）用真实事件复刻不抛；openviking capture.mjs 的 parts.filter（extractPartsFromPayload 至少返回 []）安全。

诚实说明（待维护者补齐）

运行进程未开 Node inspector，无法非侵入 attach 抓 stack；且无 web 插件的 CLI/headless 不触发，复现依赖 web 专属插件。故未锁死到具体那一行 .filter，仅收敛到「agent/turn-stopping 串行下发 + dsh-mnemon 监听者是唯一候选热区」。dsh-v0.1.2-alpha.5 → origin/master 之间未发现针对本 bug 的修复。

建议的修复方向

• 在 dsh-agent-loop/lib/index.js 的 turn() catch（约 577 行）把 error.stack 一并带进 turn/end reason（或 agent/error），即可稳定复现完整 stack。
• 排查 agent/turn-stopping 监听者（尤其 dsh-mnemon.scheduleIdleReview 及其中对 this.agent.session.events 的访问）在 turn 收尾瞬间对某一 undefined 数组的 .filter 调用。

复现用会话

• session-0417531c-7316-4dd8-8988-35fe5a0f9ad6（deepseek-harness 工作区）

[argszero]

你的收敛结论在 49a606bc（alpha.5 merge 提交, 本地已 checkout）上逐点验证为结构性成立, 而且可以比"唯一候选热区"更进一步: step/end → turn/end 之间那段代码里, 能产生"已落盘 turn/end ERROR"的抛出点只有一处。

热区证明（为什么只能是 agent/turn-stopping 监听者）

agent-loop/src/agent.ts turn() 的收尾段:

step 内层 try/finally: 先 append step/end          ← 若这里抛, 无 turn/end 记录
:303  if (turnEnds && this.inbox.nextStep.length === 0)
:305  await this.dispatch.serial('agent/turn-stopping', { turn, signal })   ← 唯一可抛区
:306  signal.throwIfAborted()                       ← 若中止, reason='aborted' 非 'error'
:309  break → 外层 catch（无）→ finally append turn/end

你观察到的 turn/end ERROR 记录存在, 排除: step/end 抛（会跳 finally 前? 不——step/end 在内层 finally, 它抛会先走外层 catch, 但那样 reason 也记 error… 实际上 step/end append 若抛, 走的是外层 catch :312, 同样产出 error 记录。所以严格说热区 = "step/end append 之后到 turn/end append 之前"。这段里: :303 的 nextStep.length 是数组访问不会抛; :306 throwIfAborted 只产 aborted; 唯一在 step/end 与 finally 之间能抛非中止错误的就是 :305 的 serial dispatch）; turn/end append 本身若抛则没有 ERROR 记录（与证据矛盾）。结论: 崩溃必在 serial dispatch 内部——即某个 agent/turn-stopping 监听者（或 dispatch 机制本身, 后者是稳定代码）。你的"dsh-mnemon 监听者是唯一候选"在你的 bundle 内成立。

机制补全: 为什么一个监听者 bug 会变成整轮失败（serial 的传播语义）

关键在事件分发的不对称, 你的报告里没点出这一层:

• agent/dispatch.ts 的 emit 分支: 逐监听者 try/catch + rejection 记日志（"listener threw"）——观察者错误被包含。
• vendored Cordis events.ts 的 serial（:204-214）: for … await cb(...), 裸 await, 无 try/catch——监听者 throw 直接向调用方传播。
• parallel 则 allSettled 后 AggregateError。

agent/turn-stopping 走的是 serial（:305）→ 监听者一抛, 直通 turn() 外层 catch :312 → 非 LlmError 拍平为 {message: errorChain(error), code:'UNKNOWN'}（:317-323）→ finally 落盘 error reason。所以"答案已写盘但本轮被判失败"不是 mnemon 的偶发, 而是分发模式的结构性后果: turn-stopping 的任何监听者抛错都能杀死一个内容已成功的轮次。

两个旁证:

1. 错误栈在 durable 记录里确实不可得。throwError（:212-217）会把原始 error（含 stack）经 agent/error 的 contained emit 发给在途监听者——但非持久; durable 的 turn/end reason 是 LlmFailure（types.ts:200-204, message+code）; errorChain（llm/src/error.ts）只渲染 message+cause 链, 从不含 stack。TypeError 的 message 只有操作名, 无文件/行号——你的诊断受限判断正确, "把 stack 带进 reason"方向正确。注意这是 durable 载荷, 建议作为 catch 处的可选加字段（非 LlmError 分支把 error instanceof Error ? error.stack : undefined 并入, known event 加可选字段, 旧读者忽略, append 的 isJsonValue 校验 stack 是 string 无碍）。
2. 面不是 web 独有。树内 hooks-codex（:260）与 hooks-claude-code（:270）都注册了 agent/turn-stopping serial 监听者, 且 Stop 监听者 await runPoint(...) 无局部 catch → hook 进程出错同样会整轮失败。你的"CLI/headless 不触发"只对你的 bundle成立; 传播危害是通用的（hooks 配置加载失败有 catch, 但 Stop 执行路径没有）。

修复建议（给维护者的方向, 按性价比排序）

1. 在 agent-loop 分发点包含监听者错误——mirror dispatch.ts emit 分支的逐监听者 try/catch + logger.warn, 或对 :305 单独 catch。语义安全: 树内所有 turn-stopping 监听者都返回 void（hooks 用 agent.steer 副作用续轮, 无人 bail）, serial 的 bail/veto 语义在此事件上没有使用者, 包含错误不丢语义。效果: mnemon 的崩溃从"假轮失败"变成一行可诊断 warning, 所有 profile 免疫。
2. stack 进 durable reason（你的建议 1）: 上述 catch 的非 LlmError 分支并入可选 stack 字段。
3. mnemon 自身的 .filter 修复属插件侧（我无法读其源码）——但 1 落地后, 这类三方 bug 不再能污染轮次结果, 修复紧迫性降为"日志噪音"。

顺带: #5456（yc-eagle, 最终 todo 项无限 spinning）疑似同族下游症状——若 todo 收尾依赖 turn/end 成功路径或 turn-stopping 之后的某步, 假失败会让 UI 永远停在 in-flight; 值得用同一 lens 查一遍。你的复现会话 id 已留, 若需要我也可以按上述 :305 catch 语义做一条最小 repro（不依赖 web 插件, 直接对 serial dispatch 注入抛错监听者）。