[Bug 线索] 网关偶发 tool_calls 空 id 帧，引擎未防御导致会话 400 崩溃

[Zn-Dk]

现象

会话偶发整体崩溃：某一轮的工具调用执行完毕后，下一轮请求直接收到网关 400 INVALID_REQUEST，整个 turn 以 error 结束。用户只能靠手动说"继续"重新拉起下一轮。会话日志本身也因此留下损坏（空 callId 三处不一致）。

复现时间线（同一会话内）

时间（UTC+8）	事件
17:21:29	turn 4 开始，用户贴两张截图 + runtime context
17:21:39	turn 4 step 1：两个 run_code 调用执行完毕
17:21:39	turn 4 step 2：重建请求发往网关 → 400 INVALID_REQUEST
17:21:39	turn 4 以 error 结束，会话崩溃

seq 级日志证据

该 turn 的第二个 tool-call（index 1）在增量流中 id 变化如下：

seq	事件	id
49570	tool-call-delta index 1	call_function_xxx_2 ✅
49571	tool-call-delta index 1	call_function_xxx_2 ✅
49572	tool-call-delta index 1	call_function_xxx_2 ✅
49573	tool-call-delta index 1（最后一帧）	"" ❌
49575	block-end index 1	block.id: "" ❌

该空 id 随后固化进以下历史事件：

seq	事件	受损字段
49578	assistant/message	content[1].id: ""
49583	tool/call	callId: ""
49584	tool/result	toolCallId: ""、source.callId: ""
49589	assistant/chunk（finish）	reason.error.code: INVALID_REQUEST（400）
49591	turn/end	reason.kind: error

下一轮重建请求时，这段历史被原样序列化，空 callId 变成 tool_call_id: "" 发回网关，网关拒绝，turn 崩溃。

根因定位

上游（DeepSeek 网关）在 tool_calls 的收尾 delta 帧里偶发把 id 发成空字符串——注意是空字符串 ""，不是省略字段。证据在引擎侧 packages/llm/llm-deepseek/src/translate.ts 的这段逻辑：

// 现状（第 159 行附近）
if (call.id !== undefined) block.callId = call.id

• 如果那一帧是省略 id（undefined），这个判断不通过，block.callId 会保留前三帧累积的正确 id；
• 日志里实际出现 ""，只能说明上游那一帧真的发了个空值，被 !== undefined 判成"有效"，覆盖掉了正确 id。

随后 closeBlock 再固化：

// closeBlock 内（第 71 行附近）
id: CallId(block.callId ?? ''),

空串仍是空串。而 packages/llm/llm/src/assembler.ts 本有兜底：

id: partial.toolCallId ?? CallId(`call-${index}`),

但 block-end 携带的 block 是权威、优先返回（if (partial.block) return partial.block），所以这个兜底被绕过，空 id 一路进历史。

崩溃链

上游空 id 帧（""）
  → translate 覆盖正确 id
  → 空 callId 固化进 assistant/message、tool/call、tool/result
  → 下一轮重放 tool_call_id: ""
  → 网关 400 INVALID_REQUEST
  → 整个 turn 崩溃

修复建议

translate.ts 只接受非空字符串 id：

if (typeof call.id === 'string' && call.id.length > 0) block.callId = call.id

并在 closeBlock 对仍为空的情况兜底生成内部 id，而不是 ?? ''：

id: CallId(block.callId && block.callId.length > 0 ? block.callId : `call-${block.index}`),

这样上游再发空 id 帧，历史里仍保留正确 id（或至少是可用的内部 id），会话不会崩。

补充

• 已用 dsh-session-repair 插件补全该会话的空 callId，会话恢复可继续对话，证明此链路可自愈，但治标不治本。
• 如需完整日志片段（已脱敏）复现，可提供。

[argszero]

Verified every anchor against rc.2 (HEAD b150a55). Your diagnosis is exact — and this thread is the 5th instance of a documented wire-identity family, with one genuinely new layer in your fix.

Family convergence: the identity-loss class

Your crash chain (empty id:"" delta → !== undefined accepts it → correct id overwritten → closeBlock flattens to "" → block-end bypasses the assembler backfill) is the exact mechanism reported in #1713 (SGLang explicit-null) → #2090 (Xreative) → #2169 (official DeepSeek, empty-string variant) → #2343 (lanjie8, v4-flash, empty-string + patch) → #2540 (SiliconFlow, empty-string + patch) → #2855 (guzhou0102, the block-end short-circuit you rediscovered) → #2997 (opencode.ai zen) → #4265 (opencode.ai zen/go relay). Yours is the second report through an official DeepSeek endpoint after #2169, and the first to pin the failure to the final delta frame of the stream.

rc.2 verification of your anchors:

• translate.ts:159 if (call.id !== undefined) block.callId = call.id — "" passes; and :160 if (call.function?.name !== undefined) has the same gap for name
• closeBlock (:70-72) id: CallId(block.callId ?? '') — empty stays empty
• assembler.ts:70 partial.toolCallId = chunk.id — unconditional overwrite, while :71 if (chunk.name) already has a truthy guard (the id/name asymmetry the family has flagged since Bug: tool-call id/name overwritten by empty strings from OpenAI-compatible providers (every tool call becomes `unknown tool ""`) #2540)
• assembler.ts:103 if (partial.block) return partial.block — block-end is authoritative; the partial.toolCallId ?? CallId('call-${index}') backfill at :113 is never reached

Sharpening: the replay-time 400 is the secondary symptom — this is load-time poison

Your table shows the empty id persisting into tool/result (toolCallId: "" + source.callId: ""). rc.2's session-load validation (packages/core/session/src/index.ts:340-341) throws message must have tool source for exactly sourceRecord['callId'] === '' — so once such a result is persisted, the session is permanently unloadable without repair, matching #2169's escalation. Your dsh-session-repair plugin was load-path recovery, which is the right place to repair — but it also means the fix must prevent writing the poison, which yours does. Good layer choice.

Your closeBlock fallback is a genuinely new 4th layer

The family's agreed blueprint was three layers: L1 translate truthy guards, L2 assembler.ts:70 if (chunk.id) (mirroring :71), L3 assembler assemble() backfill from accumulated partials (#2855). Your closeBlock fallback (CallId(block.callId && block.callId.length > 0 ? block.callId : call-${block.index})) is a source-side id guarantee the family did not have — it makes the id non-empty at the point of creation, so every consumer of the translated stream sees a valid id, not just the assembler path. Keep it alongside L3: closeBlock guarantees non-empty, assembler backfill covers raw block-end frames from other adapters. The two are complementary, not redundant.

One completeness note: cover the name field too

Your fix targets id only, but translate.ts:160 is the identical !== undefined trap for function.name — an upstream "name": "" delta frame produces unknown tool "" (the #1713/#2090/#2997 visible symptom). The canonical form is truthy guards on both: if (call.id) / if (call.function?.name), plus if (chunk.id) at assembler.ts:70 to finally align it with :71. And the regression test should cover all three provider behaviors — missing, null, and "" — since != null alone misses the empty string (the family paid for that exact gap on #2169/#2540).

Full fix blueprint for the maintainer patch: L1 translate truthy guards (id + name) · L2 assembler.ts:70 guard · L3 assemble() backfill · L4 closeBlock source-side fallback (yours) · regression = three-state delta matrix. This one patch closes the whole identity-loss family (#1713/#2090/#2169/#2343/#2540/#2855/#2997/#4265/#4365).

[Zn-Dk]

收到，逐条确认：

1. 蓝图对齐 —— L1 translate 真值守卫（id + name）· L2 assembler.ts:70 guard · L3 assemble() 后备 · L4 closeBlock 源头兜底 · 三态（missing / null / ""）回归矩阵。全部接受。L4 定位为 source-side id guarantee、与 L3 互补不重复，这个划分很准确——closeBlock 保证"翻译流出来的就是非空 id"，assembler 后备兜住"其他 adapter 的裸 block-end 帧"。

2. name 字段补全认可 —— translate.ts:160 的 if (call.function?.name !== undefined) 确实是同一陷阱，上游 "name": "" 会产生 unknown tool ""。完整 patch 应把 if (call.id) / if (call.function?.name) 成对写成真值守卫，这跟 #1713/#2090/#2997 的可见症状对得上。我们的讨论正文只盯了 id，这里确实是漏了。

3. 我们侧已补三态回归 —— dsh-session-repair 是 load-path 恢复插件，能观察到的正是"已落盘的 identity loss"三种形态：字段缺失、显式 null、空字符串。我已经把 missing / null / "" 三态矩阵补进本仓库回归测试（findEmptyToolChains + applyEmptyToolChains 对三种形态都要求"恰好规划 + 三处 id 一致非空"），全套 13/13 通过。
See: Zn-Dk/dsh-session-repair@f998840
这层测试锁的是恢复端：不管上游丢成哪种形态，落盘后都能被可靠修复。

4. 关于 "load-time poison" —— 同意。source.callId === '' 触发 message must have tool source 是更早的、更实际的门槛，400 只是伴随的副作用。所以正确顺序是：引擎侧防写入（L1-L4），恢复侧兜读取（dsh-session-repair）。两层一起才闭环。

感谢把整个 family 串起来。L4 能进官方蓝图我很高兴，期待维护者 patch 落地。