[Bug] 空 id/name 伪 tool-call 落盘后 tool/result 校验永久失败，会话从该 seq 起卡死（0.1.7-rc.2 → 0.2.1-alpha.1 均未修，附本地已验证补丁）

[1994qrq]

TL;DR

模型（mimo-v2.6-flash）在回合尾发出空 id/name 的伪 tool-call（id:""、name:""、arguments:"{}"）时，DSH 的持久化校验存在不对称：tool/call 事件可以落盘，配对的 tool/result 事件永远过不了校验，报 format v4 tool/result at seq N requires toolCallId matching its tool source。悬空 open transaction 每轮都要补 result → 该会话从这个 seq 起永久卡死，每轮重试报同一个 seq，无法自愈。

• 影响版本：本地 0.1.7-rc.2；已核对 npm 最新发布 0.2.0-rc.2（latest）与 0.2.1-alpha.1，均未修复（见下"版本核对"）。
• 已在本地打好补丁并验证（见"修复建议"附补丁 diff 与测试）。
• 模型侧上游已有同款报告：XiaomiMiMo/MiMo#103（Phantom tool call with empty function name），但只有 DSH 侧会把它升级成会话永久报废（该 issue 场景只是网关 400）。

症状

1. 会话内任意新消息都会立即失败，错误恒定：format v4 tool/result at seq 788 requires toolCallId matching its tool source（seq 取决于中毒点，本例 788、复现第二次为 825）。
2. 失败事件不落盘（result 写不进去），因此：
   • 会话文件里全文搜不到失败文案，但 UI 每轮渲染一条红色"本轮运行失败"行；
   • 会话尾部停在一个悬空的 tool/call 上，session/list 冷读正常、打开会话后一发消息就炸。
3. 用户视角：会话"报废"，只能靠人工修文件或放弃会话。

根因：持久化校验不对称

中毒事件（真实会话导出，脱敏后）：

// seq N   assistant/message —— 回复正文之后混入空伪调用块
{"type":"assistant/message","seq":786,"data":{"message":{"content":[
  {"type":"reasoning","text":"..."},
  {"type":"text","text":"..."},
  {"type":"tool-call","id":"","name":"","arguments":"{}"}   // ← 模型/解析层产物
]}}}

// seq N+1 tool/call —— 空 id 照样落盘
{"type":"tool/call","seq":787,"data":{"callId":"","name":"","arguments":"{}"}}

两处校验的宽严不一致（dsh-session-persistence-jsonl）：

// tool/call 落盘：只做 lifecycle 匹配 —— 空 id 对空 id，照样通过
case "tool/call": {
  const lifecycle = toolLifecycles.get(callId);          // "" → 命中广告的 ""
  if (lifecycle === void 0 || lifecycle.state !== "advertised" || ...) throw ...;
}

// tool/result 落盘：非空 + 相等 —— 空 id 永远过不去
if (typeof toolCallId !== "string" || toolCallId.length === 0 || sourceCallId !== toolCallId)
  throw new SessionFormatError(`${subject} requires toolCallId matching its tool source`);

于是 tool/call 成为永远无法闭合的 open transaction：turn 恢复/续跑时第一件事就是补这个 result → 同一 seq 永久失败。

复现

1. 会话用 cline-pass/mimo-v2.6-flash，让模型围绕"反引号 / 伪 tool_call"话题写回复（或要求大量 markdown 代码块）。本机 2 小时内复现 2 次；模型自己的推理也预告了触发条件（"每次我讲到伪 tool_call、要写出 `` …"）。
2. 事件级最小复现：向任意会话尾部追加一个 assistant/message（content 含 {"type":"tool-call","id":"","name":"","arguments":"{}"}）及其 tool/call（callId:""），重启后发任意消息即触发。

注：这是模型侧已知毛刺（见关联链接），harness 无法要求上游不发，只能保证自己不被一击致死。

版本核对（是否已修）

拉取了最新发布包逐条比对：

版本	dsh-session-persistence-jsonl 校验断言集合	含 requires toolCallId matching
0.1.7-rc.2（本地）	基线	是
0.2.0-rc.2（npm latest）	与基线 diff 为空	是
0.2.1-alpha.1（最新 tag）	与 0.2.0-rc.2 diff 为空	是

→ 三个版本的 SessionFormatError 消息集合逐条一致，该问题在最新发布版依旧存在。

修复建议

方案 A（推荐，根治入口）：在 dsh-llm 的 BlockAssembler.assembled() 这一"唯一 keep/drop 决策点"把空 id/name 的 tool-call 块与 max-token 截断走同一个 mask 丢弃，消息侧与 replay 侧同源派生、不会不一致。本地补丁（已验证）：

assembled() {
  const all = this.order.map((index) => this.assemble(this.mustGet(index), index));
  const kept = all.map((block) => {
    if (this.finish.kind === "max-tokens" && block.type === "tool-call") return false;
    if (block.type === "tool-call" && (typeof block.id !== "string" || block.id.length === 0
        || typeof block.name !== "string" || block.name.length === 0)) return false;
    return true;
  });
  const blocks = all.filter((_, position) => kept[position]);
  // ... replay envelope 沿用同一 kept mask（既有逻辑不动）
}

效果：空伪调用在组装层被丢弃 → toolCalls.length === 0 → 按既有分支 completed 收尾，不再产生悬空 call。冒烟测试 6 项全过（毒 delta / 毒 block-end / 合法调用保留 / max-tokens 回归 / replay 同步过滤 / 全正常路径）。

方案 B（持久化层兜底）：对空 id 的悬空 tool/call 允许落一个 TOOL_NOT_STARTED 修复 result——0.2.x 已有 isExactToolNotStartedRepair 机制，可直接复用到该场景，保证 turn 总能闭合。

方案 C（对称校验，止血）：tool/call 落盘时同样拒绝空 callId/name，让失败发生在广告阶段（turn 内可重试），而不是把会话变成永久毒态。

三个方案不互斥；A 已在本地端到端验证，可直接合入。

关联 / 上游参考

• 模型侧同款：XiaomiMiMo/MiMo#103 — Phantom tool call with empty function name at end of turn（空 id/name 幻影调用，网关重放 400）
• 本仓库相关讨论：#2855 — unknown tool ""（空名工具调用，流分块机制，症状同类、不卡会话）
• SDK 侧同类：earendil-works/pi#10299 — empty tool call entries from OpenRouter
• 模型侧官方复盘（含 DeepSeek Harness 评测数据）：Diagnosing and Mitigating Tool-Call Repetition in MiMo-V2.6

环境

• DSH 0.1.7-rc.2（Windows / dsh web）
• provider cline，model cline-pass/mimo-v2.6-flash（openai-completions 兼容层）
• 会话规模约 245K tokens 上下文时高发

附带发现（供参考，可另开帖）

1. 工具表 45 个工具中没有裸 exec，但 mimo 系模型带强 exec 先验（MiMo Code code-mode 单 exec 设计），会持续尝试调用并产生 unknown tool "exec" 噪音。本地已在 dispatch 层做别名（exec → mcp__fastctx__run，历史事件保留原名），需要的话可以贴完整补丁。
2. 回复在反引号处被上游直接 finish=stop 截断（流记录：文本碎片后 finish kind=stop，无 tool_calls）——属上游生成问题，harness 侧无法根治，截断后发"继续"可续跑。

[argszero]

Thank you for a report whose diagnosis survives contact with the source. I checked every leg against a fresh tree: your mechanism is right, and two facts make it sharper — then the seam that lets this be prevented rather than only described.

1. The asymmetry is where you say, and the write path is why nothing lands

The throw is tool-role.ts:96 (toolCallId.length === 0 || sourceCallId !== toolCallId). The row admission that runs before an event is encoded — assertV4RowAdmission (session-format-v3-to-v4/src/codec.ts:62) — validates only tool/result among the tool-family rows; assistant/message gets a source-kind check (message-sources.ts:29-41) and tool/call gets nothing at all. So an empty-identity call is advertised, persists, and can never be answered — exactly the asymmetry you named.

The "the failing event never lands" half is mechanical, and it is worth stating because it is what makes the wedge permanent: appendLines (session-persistence-jsonl/src/index.ts:1324) calls encodeEventBatch → eventLines → sessionFormatCatalog.encodeCurrentEvent, which is the v4 codec's encodeEvent (session-format/src/catalog.ts:164) — i.e. assertV4RowAdmission — and that runs before the append handle is opened (:1325, then :1326). The row that fails is the closure result the loop writes for the pending call, so the file keeps the dangling tool/call, the batch is never written, and every retry recomputes the same seq. That is the permanent wedge, and your patch C is the minimal core fix — refuse the empty callId/name at the advertise stage, where the turn can still retry, instead of at a stage where the transaction can already be open.

2. A response-stream seam exists, and suppressing a block needs no index renumbering

llm/stream is a waterfall over the chunk stream, not only over the request: (options: GenerateOptions, next: () => AsyncIterable<StreamChunk>): AsyncIterable<StreamChunk> (packages/llm/llm/src/index.ts:75, dispatched at :1136-1141). A listener may therefore return a wrapped iterable. The agent loop consumes exactly the waterfall's output (core/agent-loop/src/agent.ts:436-443) and feeds both the BlockAssembler and the durable attempt accumulator from it — so a filtered stream is filtered uniformly for the assistant message and for the replay record, which an assembler-level drop (your 方案 A) does not give you.

Dropping a block is index-safe: BlockAssembler keys partials on a Map and records order at first sight (llm/src/assembler.ts:39-40, :52-59), so a suppressed index leaves no hole that anything downstream would have to renumber.

3. What the adapter already tells you, before the arguments start

llm-pi-ai/src/stream.ts:174-193: block-start carries no identity; the first tool-call-delta carries id and carries name only when nonempty. So your phantom is visible at the first delta — id: '' with no name — with block-end's authoritative block as the confirmation. That is early enough to decide before a single chunk of the block has been emitted.

What I am doing with it

I am preparing a guard on that seam that suppresses an empty-identity tool-call block before it is advertised — no tool/call is written, so there is nothing to poison. Its honest boundary: prevention only. It cannot repair a log that is already poisoned, because no nonempty id exists to write a result against — which is why your patch C remains the fix that closes the class.

[argszero]

The diagnosis above holds, and it has a preventive half that does not need the write path. I packaged it as a plugin and published it:

@argszero/dsh-phantom-tool-call-guard@0.1.0 — https://www.npmjs.com/package/@argszero/dsh-phantom-tool-call-guard (source: https://github.com/argszero/dsh-phantom-tool-call-guard)

npm install @argszero/dsh-phantom-tool-call-guard@0.1.0

It mounts itself; the package ships a bundle patch, so a deployment using the bundle convention adds one entry:

- insert:
    - id: phantom-tool-call-guard
      name: '@argszero/dsh-phantom-tool-call-guard'

Why the response side of llm/stream is the right seam for this

BlockAssembler.assemble() writes partial.toolCallId ?? brandString<ToolCallId>('call-' + index), and '' is not nullish — so the harness's own fallback is defeated by exactly the value the adapters emit (known?.id ?? ''). The gate therefore acts in one place only: where core's guard is defeated.

The listener wraps the return value of the llm/stream waterfall (prepend: true, so it is the last transformation before the consumer):

ctx.on('llm/stream', (options, next) => guardChunks(next(), policy), { global: true, prepend: true })

That position is not a preference. The loop consumes exactly that value — packages/core/agent-loop/src/agent.ts, for await (const chunk of stream) — feeding one AssistantStreamAttempt that both assembles the durable assistant/message and records the raw chunks for replay. So a chunk repaired there is repaired in the message and in the record it will be replayed from, and the two cannot disagree afterwards. (The request side of the same waterfall is read-only — a loop-built request arrives deep-frozen — but the returned stream is a value a listener may replace.)

What it decides, and where it deliberately stops

evidence about the block's identity	the assembler will	verdict
block-end.block.id present	use it verbatim (a closed block is authoritative)	keep
block-end.block.id empty or absent	write id: '' — this is the poison	answer: write call-phantom-<index>
last delta's id is ''	write id: '' — the poison	answer: write call-phantom-<index>
last delta's id is undefined	fall back to call-<index>	keep, id-never-arrived
deltas stated an id, block-end arrived without one	lose the id the stream already declared	answer: restore it, id-lost-at-close

Three deliberate boundaries:

• Only the identity is repaired. An empty tool name is left exactly as the model produced it — inventing a name would dispatch a tool the model never asked for, while a nameless call fails honestly at the registry and its durable tool/result closes the transaction either way.
• The written id is namespaced (call-phantom-<index>) so a reader can tell at a glance that the provider did not write it. A value that looked like the provider's own would be a lie about provenance.
• Mode-tunable, and the typo is safe. answer (default) writes the id; suppress drops the block instead (the posture the harness already takes for tool calls it cannot execute — max-token truncation); observe decides and counts exactly as answer would and emits the stream unchanged; off installs no listener. An unrecognised mode spelling resolves to observe, because the failure mode of a typo has to be the one that changes nothing. phantomToolCallGuard.snapshot() returns the counters, the bounded history and the plugin's own declared blind spots.

What it does not do, and why your patch is still needed

It is preventive, not curative. A session whose tool/call already landed with callId: "" cannot be repaired from here — the refusal happens while the encoder builds the row, before the append, and reaching a log that already contains the dangling call needs the write path, which is core's. The local patch in your report and this plugin are the two halves, not alternatives: the patch rescues an already-poisoned log, the plugin stops the next one from being produced.

Evidence

• The integration suite builds a real Cordis context, a real LlmRuntime and the real llm/stream waterfall; it feeds the repaired block to the shipped BlockAssembler and then to the shipped assertV4RowAdmission (session-format-v3-to-v4/src/codec.ts) — the assertion is "the row this boundary refused is the row it now admits", not a paraphrase. The control arm runs the same chunks with the plugin absent and reproduces your refusal, format v4 tool/result at seq N requires toolCallId matching its tool source, verbatim.
• The listener position is pinned in both directions: a block contributed by a listener mounted inside the guard is covered; one contributed by a listener mounted outside it is not (and is reported as not covered rather than silently repaired).
• 33 defect-injection arms — one distinction removed per arm — are all caught, none silent; the suite is green on the 0.1.7-rc.2 and 0.2.0-rc.2 lines with every harness package pinned to the line.
• Zero runtime dependencies: every bare import is import type, erased at emit, so the shipped lib/ reaches nothing but its own modules. That is deliberate — a plugin's own dependency can materialize a second copy of a harness package in a profile deployment, a failure this repository has already shipped more than once.

Happy to adjust the seam or the default if you would rather see the identity minted somewhere else; the gate itself is a pure chunk transformer and it is the only place the decision lives.