REQUEST_EXTENSION 失败吞掉内层原因，会话日志只留 message 与 code

[YOUKNOWWHOOO]

环境

操作系统：Windows 11 家庭版，版本 10.0.26200，64 位，AMD64。

运行时：Node.js v26.9.0（fnm 管理）、PowerShell 7.6.6。

软件：@deepseek-ai/dsh 0.1.7-rc.2（经 npx 安装，以 dsh web 启动）；profile 组合为 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app；dsh-llm-deepseek 与 dsh 同版本。

观测时间：2026-09-29（CST，UTC+8）。

现象

待分配-3 的失败发生时，内层异常不进入任何落账。会话日志的 assistant/attempt 与 llm/retry 事件只含 { message: "DeepSeek request extension preparation failed", code: "REQUEST_EXTENSION" }，不含内层错误的消息、类型或来源；Web UI 的呈现与之同源。排障者据此无法知道失败发生在哪个贡献者、内层错误是什么。

代码证据

包装点在抛错时其实携带了内层，位置是 dsh-llm-deepseek/lib/index.js:1349 的 { cause: error }。落账层不含该 cause：本机多次现场读数中，assistant/attempt 的 finish.reason.failure 与 llm/retry 的 failure 均只有 message 与 code 两个字段。

影响

错误发生时无从下手。故障的可见面是一句不含定位信息的短语，排障必须阅读多个包的源码链路。

建议

1. 把内层 cause 的 message（必要时含类型）写入失败事件落账，至少 llm/retry 可加一个截断字段。
2. 或让错误消息自身携带内层摘要。
3. UI 呈现如维持现状，也建议在诊断详情里可展开 cause 链。

[argszero]

Confirmed at source — with one correction to the mechanism that changes what a fix has to touch. Nothing drops the cause on the way into the log. The cause is never in the payload to begin with, and that is deliberate.

LlmError carries two different things, and only one of them travels.

packages/llm/llm/src/index.ts:96 holds the live Error, whose .cause your citation sets through super(message, code, options) (:120), alongside a frozen readonly failure: LlmFailure (:98) built at :122-129 from exactly six keys — message, code, status, providerRetryAfterMs, requestId, offloadImages. LlmFailure (packages/llm/llm/src/types.ts:41-59) has no cause field, and failure is what travels:

• packages/core/agent-loop/src/agent.ts:361 takes error.failure — the projection, not the error — lands it as assistant/attempt's finish.failure at :482, and re-throws a fresh LlmError(finish.failure.message, finish.failure.code, finish.failure) at :490;
• llm-retry writes the same object into llm/retry (packages/llm/llm-retry/src/index.ts:175), and its durable-boundary invariant validates precisely that shape (packages/llm/llm-retry/src/invariant.ts:21-45).

So your two observations — assistant/attempt.finish.reason.failure and llm/retry.failure both holding exactly message and code — are the same object seen twice, and the rest of your reading follows: the consumer has nothing to render because there is nothing there.

The choice is not an oversight. cause is an arbitrary live object graph — in this case an Error from a JSON.parse or a readFileSync deep in the collector, with its own stack, errno and possibly cyclic references — while the session log is append-only, replayed, and invariant-checked. failure is the boundary between "a runtime error happened here" and "a fact that can be written down and read back forever". Widening it means widening the projection on purpose; the log cannot be taught to keep an input it never received.

On your three suggestions:

1. Right direction, and small. Add one optional field to LlmFailure — a pre-rendered, truncated string (causeSummary, taking cause.message and optionally cause.name), populated at the LlmError construction site. String-only is what keeps it serializable, replayable, and inside the invariant's ability to validate it; copying the object is what would break all three.
2. Weaker than 1, and it costs something. Folding the inner summary into message puts prose in front of machine consumers: failure.code drives routing and retry classification today, and a message that now contains a second, nested message makes every reader parse text to recover facts it already has. Add a field beside message/code; don't merge them.
3. Sequenced after 1. A detail view can only expand what the event carries, so UI work here is downstream of the payload field — and the Web UI would inherit the field for free, since it renders the same event.

The operational half is available today as a plugin. @argszero/cordis-plugin-request-extension-guard@0.1.0 — npm, source, one insert: entry in the profile patch. It wraps the extension providers inside the registry the adapter reads, which is upstream of the wrap that discards your cause, so the producer's own words survive into the host log, prefixed and made filterable:

request-extension-guard: skipped field "dsh_plugin_packages" for this request — the request still carries every other field. Producer message, verbatim: plugin-package-inventory-deepseek: <path> must declare non-empty name and version

That single line answers the question your thread is about — which contributor failed, and with what — without reading four packages. Verified on your build: 0.1.7-rc.2 → 29/29 in a clean tree with the registry package pinned to that line, and 0.2.0-rc.2 → 29/29.

Two boundaries, so the scopes don't blur:

• It makes the failure legible live, not legible in the replay. The durable payload you are asking about is core-owned; only core can widen it. That is suggestion 1, and it is still the one to do upstream.
• With repairProfileManifest: true it also removes the failure itself rather than describing it — the manifest case in profile 清单缺 `version` 时，经官方适配器发出的每一次请求都在 HTTP 之前失败 #8265, which is the same reporter's companion thread and the most common producer of this code path.