[Bug] V4 写侧 admission 不校验 tool-call 的 id/name：会话或永久打不开、或每次请求 400（0.1.7-rc.2 桌面端，含实测会话与帧级证据）

[shuaige1145]

V4 写侧 admission 不校验 tool-call 的 id/name，可写出自己读不回来的会话日志

English abstract: the V4 write-side admission validates tool/result rows but neither the
tool-call blocks inside assistant/message rows nor the callId/name of tool/call
rows, while the reader (Relationships.tool() → text(block["id"], "tool call id"), and
assertV4ToolResultMessage) and the pi-ai replay serializer both require them to be
non-empty. One provider tool call with an empty function name therefore produces a session
log DSH can never read back: either the session refuses to load, or it loads and every
subsequent request is rejected by the provider with HTTP 400.

Summary

写入侧 assertV4RowAdmission（@deepseek-ai/dsh-session-format-v3-to-v4）在
assistant/message 行上不校验 content 里 tool-call block 的 id/name，在 tool/call
行上也不校验 callId/name —— 只有 tool/result 行会走 assertV4ToolResultMessage。
而读取侧 Relationships.tool() 用 text(block["id"], "tool call id") 硬性要求非空，
重放侧（@deepseek-ai/dsh-llm-pi-ai → pi-ai 的 openai-completions 序列化）把
block.name 原样写进 tool_calls[].function.name。

于是 provider 只要返回一次 function.name 为空（id 也可能为空）的 tool call，
DSH 就会写出自己读不回来的日志，落进两种都不可自愈的状态：

• A：id 为空 → 会话永久打不开：
  stored session "…" is corrupt: … SessionFormatError: tool call id requires a nonempty string
• B：id 非空但 name 为空 → 会话能打开，但之后每一次请求都被 provider 拒绝：
  400 {"code":"400","message":"Param Incorrect","param":"messages[N].tool_calls[0] is missing a function name"}

Reproduction

路由：provider=mimo、model=mimo-v2.6-flash、api=openai-completions（pi-ai 适配器）。

1. 模型产出畸形 tool call（一次会话里 2 小时内命中 2 次）：function.name 为空字符串，
   arguments 是 <parameter=command>…</parameter> 形式的文本；该 arguments 的 JSON
   首个 key 恰好是它想调的工具名（例如 pwsh）。
2. DSH 正常落盘两条记录：
   • assistant/message：{"type":"tool-call","id":"","name":"","arguments":"…"}
   • tool/call：{"callId":"","name":""}（name/arguments 与上面的 block 深相等）
3. 下一步写 tool/result 时被写入侧拒绝：
   format v4 tool/result at seq N requires toolCallId matching its tool source
   （UI 显示“本轮运行失败”），日志停在 tool/call 之后，turn 保持打开。
4. 重开该会话 → 报 A 类错误。
5. 把两个空 id 补成同一非空 call_… 后可正常打开；再发一条消息 → 报 B 类错误
   （tool_calls[0] is missing a function name，来自 messages[298]）；
   把 name 补成 pwsh 后请求才发得出去。

实测留证（DSH 0.1.7-rc.2 桌面端 nightly win-x64，Windows 11 10.0.26100 x64，format v4）：

会话 id	记录数	坏点	症状	修复前 sha256
session-39e54170-88eb-4053-b340-915de9e710e4	790	seq 774（block）/ 775（tool/call）	A + B 都命中	cb9121cd511c958fb5b1d63a457db1dd70daceb1202d94010ad5771d4aa8d92e
session-3a4e7086-f780-47d8-8c0e-6b2f1e379ef6	391	seq 384 / 385	A（未走到 B）	65e059e10a47ab258f46f1f7f57d959a8793949e6d2989765b5d6e0b9e2213a1

（上表 sha256 是“已补 id、未补 name”的状态；更早的纯损坏态分别是 c57a100c…、00a76788…。
两次修复都只改 4 个字段 —— 两个 id/callId、两个 name，arguments 一字未动，
容器层只重压含这些记录的那一帧，其余帧字节完全保留。）

Current behavior

• 写入侧接受了一条自己读取侧必然拒绝的记录，容器与格式层都没有兜底。
• 读取侧把损坏直接暴露为用户可见的 历史加载失败，且没有官方修复入口。
• 自带崩溃恢复救不了 A 类：interruptedTurnClosers（@deepseek-ai/dsh-session）
  会按 block.id="" 合成一个 toolCallId="" 的 tool/result，
  这个合成结果同样过不了写入侧 admission，于是修复动作本身失败，会话永久不可读。
• B 类更隐蔽：会话可读、可继续输入，但每次请求都在 provider 侧 400，
  用户只看到“本轮运行失败”，日志里每次追加一个失败的 turn/end。

Expected behavior

任一即可（建议 1 + 3）：

1. 写入侧校验：在 assertV4RowAdmission（encodeEvent 的唯一入口）补规则 ——
   assistant/message 的每个 tool-call block 必须有非空字符串 id 与 name；
   tool/call 必须有非空 callId/name，且 name/arguments 与已广告的 block 一致
   （即把 Relationships.tool() 的判定提前到写入前）。宁可拒绝这一行，
   也不要写出一条读取侧必然拒绝的记录。
2. provider 边界拦掉：pi-ai → durable content 的转换处（@deepseek-ai/dsh-llm-pi-ai）
   遇 function.name 为空时不要落成 tool call（降级为 assistant text 或判为
   MALFORMED_RESPONSE），因为空名 tool call 在任何 OpenAI 兼容 provider 上都无法重放。
3. 兜底与自愈：interruptedTurnClosers 不应为非法 callId 合成结果；
   读取侧遇空 id/name 时可规范化（填占位 id/name）并把事件标记为已修复，
   而不是让整个会话不可读；至少要在 admission 失败时给出指向具体 seq 的可操作诊断。

Environment

• DSH 桌面端 0.1.7-rc.2（nightly 通道，win-x64；resources/app-update.yml →
  download.deepseek.com/dsh-desk/feeds/win-x64/）
• OS：Windows 11 专业版 10.0.26100 x64
• DSH_HOME：%USERPROFILE%\.dsh
• 日志：session format v4（sessions\<cwd-key>\<sessionId>\session.v4.jsonl.zstd，多帧 zstd 容器）
• 模型/路由：mimo/mimo-v2.6-flash，api: openai-completions
  （source.replayState.response.kind = "pi-ai"，stopReason: "toolUse"）
• 受影响会话：见上表两个 id

附录：定位

• 写入侧入口：@deepseek-ai/dsh-session-format-v3-to-v4 的 assertV4RowAdmission
  （对 tool/result 调 assertV4ToolResultMessage；对 assistant/message 只做
  assertV4DeveloperData / assertV4RetiredSyntax / assertV4SystemMessageFields）
• 读取侧规则：同包 Relationships.tool()：
  const id = text(block["id"], "tool call id") 与
  const id = text(message === void 0 ? data["callId"] : message["toolCallId"], "tool call id")
• 崩溃恢复：@deepseek-ai/dsh-session 的 openTurnClosers / interruptedTurnClosers
• 重放：@deepseek-ai/dsh-llm-pi-ai 把 durable block 映射为 pi-ai toolCall（name: block.name），
  pi-ai 再序列化为 tool_calls[].function.name
• 复现工具：按 released-V4 规则移植的校验器 + 帧级修复脚本（可提供）；
  全量体检当前 21 个 v4 日志输出 invalid=0 replay-hazard=0，
  并与 DSH 自身的 import_chat(dsh4) 读取路径交叉验证过修复结果

[xiaonerner0821]

补充一个 Anthropic Messages 协议下的复现，属于本帖的「B 类」（id 非空、name 为空 → 会话能打开，但此后每次请求都 400）。和本帖不同的是：这次 id 不是 provider 给的，而是 harness 自己补的，所以写入侧完全没报错，问题一直潜伏到下一次请求。

环境

项	值
DSH	0.2.1-rc.5（npx 安装，Windows，Web 前端）
路由	第三方 Anthropic Messages 兼容网关，api: "anthropic-messages"，适配器 kind: "pi-ai", version: 2
模型	Claude 系列（responseModel 为网关侧的 opus 路由）

发生了什么

一个很长的会话（约 6.8 万条事件）里，模型在回合末尾输出总结文字，写到一半时流被截断。网关没有报错，而是正常收尾：

• 最后一个内容块是 tool_use，没有 id、name、input；
• stopReason 为 toolUse（不是 max-tokens），usage 正常（输出 814 tokens）。

落盘的 assistant/message（节选）：

{"type":"assistant/message","data":{"step":129,"message":{"role":"assistant","content":[
  {"type":"reasoning","text":""},
  {"type":"text","text":"……## 技术概要\n\n- **后端（Go）：** 新增解析画面风格的模块。它把描述拆成两部分：文字颜色"},
  {"type":"reasoning","text":""},
  {"type":"tool-call","id":"call-3","name":"","arguments":""}
],"source":{"replayState":{"response":{"kind":"pi-ai","version":2,"api":"anthropic-messages","stopReason":"toolUse"}}}}}}

随后的事件：

1. tool/call：callId: "call-3", name: "" —— 正常写入；
2. tool/result：Error: unknown tool ""（UNKNOWN_TOOL）—— 因为 id 非空，写入成功，没有触发 [Bug] empty tool-call id/name from Anthropic Messages gateway → "format v4 tool/result requires toolCallId matching its tool source" crash (fix provided) #10732 / [Bug] 空 id/name 伪 tool-call 落盘后 tool/result 校验永久失败，会话从该 seq 起卡死（0.1.7-rc.2 → 0.2.1-alpha.1 均未修，附本地已验证补丁） #9215 那条 requires toolCallId matching its tool source 崩溃；
3. 下一个 step 把历史发给上游，网关 400：

   400 {"error":{"type":"<nil>","message":"***.***.content.1.tool_use.name: String should have at least 1 character ..."},"type":"error"}
   

4. 用户之后在这个会话里再发任何消息，都报同样的错（只是下标变成了 content.3）。会话永久不可用，只能弃用或从中毒点之前分叉。

为什么 id 是 call-3 而 name 是空串

@deepseek-ai/dsh-llm 的 BlockAssembler.assemble()（0.2.1-rc.5 lib/index.js 约 1031–1036 行）：

case "tool-call": return {
  type: "tool-call",
  id: partial.toolCallId ?? brandString(`call-${index}`),
  name: partial.toolCallName ?? "",
  arguments: partial.toolCallArguments
};

id 缺失时会兜底成合法的 call-<index>，name 缺失时却兜底成 ""。而丢弃不完整工具调用的逻辑只在 finish.kind === "max-tokens" 时生效。这次网关把截断报成了 toolUse，于是这个空名调用被当成正常调用保留了下来。

结果是：id 有兜底，写入侧和 #7944 提到的读取侧校验都能通过；name 没有兜底，也没有校验，到了 Anthropic 端点一定被拒。

建议（和本帖、#9048 的方向一致）

• 组装阶段：name 为空的 tool-call 不应进入 assistant/message。可以像 llm-deepseek 的 empty tool identity 那样作为 MALFORMED_RESPONSE 拒绝，或者按「截断」处理，丢弃这个调用并重试/结束本步；
• 写入 admission：assistant/message 里的 tool-call 块和 tool/call 行都校验 name 非空（本帖主张）；
• 回放序列化：作为兜底，序列化时跳过 name 为空的 tool-call 及其配对的 tool-result，至少让已经中毒的会话能自愈。

另外，社区插件 @argszero/dsh-phantom-tool-call-guard（见 #9215）只修空 id；对「id 缺失由 assembler 补齐、name 为空」这种情况它判定为 id-never-arrived 并保留，所以拦不住这次的问题。