REQUEST_EXTENSION 报错把 cause 链完全吞掉：终端、会话日志、Web UI 三处都看不到真实原因

[Puwenhui-Me]

现象

官方 DeepSeek 适配器在 prepareExtensions 内部失败时，用户能看到的只有：

本轮运行失败 DeepSeek request extension preparation failed
REQUEST_EXTENSION

而被包装的 cause——唯一指明真实失败原因的部分（例如上面那条 inventory 的 cannot resolve active package）——在任何地方都观察不到：

• 终端：没有任何日志行；packages/llm/llm-deepseek/src/adapter.ts 里包装成 LlmError 的 catch 处没有 logger 调用；
• 会话日志：失败的轮次完全不落盘——该会话的 session.jsonl.zstd 只有一行 177 字节的 session 头；
• Web UI：错误投影只显示顶层 message 和 code，cause 链被截断。

定位这个问题最终靠的是往 adapter 里临时加 console.error 打 cause，再用 dsh web --port 3081 起隔离实例复现。

建议

1. adapter 的 prepareExtensions catch 处（以及理想情况下所有 LlmError 包装点）在 rethrow 前用 logger 打出完整错误链——代码库里已有现成的 errorChain(error) 工具（agent-loop 的 warn 在用）；
2. 考虑在面向模型的错误投影里保留 cause 链，让 Web UI 能展示准备失败的原因而不只是失败本身；
3. 失败的轮次最好也向会话日志追加一条错误事件，事后取证不必依赖终端还开着。

关联：本次的触发点是源码运行下 inventory 解析器抛错（另一帖），但可观测性缺口是独立的——任何 REQUEST_EXTENSION 失败都会撞上它。

[argszero]

源码侧核实（本地 0.1.2-alpha.1 = cd5ef81），你的三个表面判断基本准确，补几条你没点到的事实——其中一条比你说的更严重，一条需要修正。

① 包装点无 logger（确认，且范围比你说的广）：

• adapter.ts:621-628 的 catch 直接 throw new LlmError('DeepSeek request extension preparation failed', 'REQUEST_EXTENSION', { cause: error })，无任何 logger——确认。
• 但更结构性的：packages/core/agent-loop/src/agent.ts 全文件零 logger 调用（grep 无任何匹配）。也就是说"终端看不到 cause"不是这一个包装点的疏漏，而是整个 agent-loop 错误路径都没有日志面——任何请求失败（RATE_LIMIT/超时/传输错）都不会在终端留下 errorChain。这是比"某个 catch 没打日志"更大的缺口。

② cause 链在失败表面被系统性丢弃（机制确认）：

• agent.ts:316-323 的 catch：error instanceof LlmError ? error.failure : { message: errorChain(error), code: 'UNKNOWN' }——LlmError 走 failure（只有 message+code），cause 不在 failure 里；只有非 LlmError 才享受 errorChain 全链渲染。
• 而 errorChain（llm/src/error.ts:114，带 circular-cause 守卫）本来就存在且被 webhook（session.ts:87）、agent-loop 的 UNKNOWN 兜底（agent.ts:315）使用——工具现成，只是 LlmError 分支没用它。修复 = LlmError 包装时把 cause 渲染进 message 或 failure 增加 causeText 字段，一处改动让所有 LlmError 包装点（adapter/pi-ai/deepseek 全家）同时受益。
• Web UI 只投影 failure.message + code——所以"本轮运行失败 DeepSeek request extension preparation failed | REQUEST_EXTENSION"是设计使然：failure 表面就没有 cause。

③ 会话日志"只有 177 字节头"需要修正/补充：

• agent.ts:326 在 finally 里无条件 session.append('turn/end', { turn, reason: turnEnds! })——即使 catch 到错误，turn/end error 事件也会落盘。所以中途 step 失败（包括 REQUEST_EXTENSION）应该在日志里留下 turn/start + turn/end error 两行。
• 你观察到"只有头"，可能的原因：① 错误发生在 turn() 之前（如 resume/初始 anchor 路径 :506 request/header 之前的阶段）——那个路径确实没有 turn/end; ② write-behind（~200ms 批量窗）未刷新你就查了文件; ③ 进程崩溃前未 flush。若你能确认是哪条路径（新会话首次请求 vs 已有会话继续），可以进一步定位——但这不影响修复结论：无论哪条路径，错误事件都不该依赖终端。

④ 修复建议（按成本排序）：

1. agent-loop 层加一条 logger.warn + errorChain（agent.ts:316 catch 处）——一个站点覆盖所有请求错误的终端可观测性，ctx logger 现成;
2. LlmError failure 携带 cause 渲染（llm/error.ts）——让 adapter 包装点的 cause 自动进入 message/UI;
3. 会话日志侧：确认 turn/end error 事件是否带 failure.cause 字段（当前只有 message+code），若带则取证面完整。

关联 #5172：你那个 inventory 插件触发点（cannot resolve active package）正好是 cause 被吞的实例——两个缺口（触发源 + 可观测性）分开修，本帖是后者的通用修法。