Web Chat: history fails to load ("received more than one start Match") when the model reuses tool-call IDs across steps

[GoldenZqqq]

Summary

When a session's history is replayed into the web Chat view, the conversation assembler hard-throws if two tool/call events carry the same callId. Some models/providers (e.g. moonshotai/kimi-k3 via an OpenAI-completions endpoint) emit per-message tool-call IDs like edit:0, read:0, pwsh:0 — tool name + a per-step index — which restart numbering in every assistant message. Any session that reuses an ID in a later step (very common with edit-retry loops) then becomes permanently unloadable in the Chat view:

Failed to load history: conversation Context 9:tool-calledit0 received more than one start Match (internal)

The session data itself is intact — the Trajectory view (separate node definitions) still renders fine and the session JSONL is well-formed — but the Chat view only shows a stale partial tail (whatever was live-streamed before the last reload) plus the red banner. "Load earlier" cannot recover it either.

Environment

• dsh 0.1.1-rc.2 (latest release at the time of writing), --profile web
• Model moonshotai/kimi-k3 served through a third-party OpenAI-completions-compatible aggregator endpoint (provider name withheld for privacy)
• Windows 11, Chrome

Evidence from a real session

A real session reached 13 turns / 233 steps / 271 tool calls. Because call IDs restart per step, IDs collide within a turn:

• turn 8: edit:0 issued at steps 2, 4, 5, 6, 7, 19, 20, 26, 27, 33, 34 (11 starts)
• turn 9: edit:0 issued at steps 7–12 (6 starts) → this is the Context 9:tool-calledit0 in the error

On reload, history replay hits the second tool/call with callId: "edit:0" inside turn 9, throws, and everything not already live-rendered is dropped from the Chat view (the visible tail stopped mid-turn-8 — roughly 1.5 h of subsequent work was invisible in Chat while Trajectory showed it fine).

Root cause chain

1. packages/client/ui-conversation/src/client/conversation-nodes/tool.ts — toolDefinition.match uses the raw callId as the context identity:

   match: (event) => {
     if (event.type === 'tool/call') return { id: String(event.data.callId), role: 'start' }
     // ...
     return { id: String(event.data.message.source.callId), role: 'update' }
   }

2. packages/client/runtime/src/client/sessions/conversation-assembler.ts — acceptMatch() (and the same guard in applyPendingMatches()) hard-throws on a second start for the same key:

   if (role === 'start' && context?.start !== undefined) {
     throw new Error(`conversation Context ${key} received more than one start Match`)
   }

   Key format from conversationContextKey(): `${kind.length}:${kind}${id}` → 9:tool-calledit0 (tool-call = 9 chars).

3. The throw escapes per-context replay and aborts the entire history load → the chat.loadError banner (packages/client/ui-conversation/src/client/locales.ts).

The implicit assumption "a callId is globally unique within a session" does not hold for providers that issue per-message sequential IDs.

Suggested fix directions

Any one of these would have saved the session. I understand external PRs are not accepted right now, so this report includes the analysis purely to help the team pick a direction — I'm happy to provide the full session JSONL, extra logs, or repro details if useful:

1. Scope the identity by location in toolDefinition.match — include turn/step (both available on event.data for tool/call) in the id, so per-step-restarting IDs cannot collide. tool/result updates need the same scoping (turn/step would have to come from the result event or seq proximity).
2. Normalize IDs at the LLM boundary — in the dsh-llm response assembler, rewrite non-unique provider call IDs into session-unique ones (e.g. prefix with a per-session counter). Fixes every downstream consumer at once, keeps the assembler's strictness.
3. Degrade gracefully in the assembler — on a duplicate start, don't throw away the whole load; fork a new context keyed by seq (console warning) or merge as an update. A single provider quirk should not make a whole session unrenderable.

Repro

1. Run a session with a model that emits per-message call IDs (kimi-k3 does), and have it retry the same tool within one turn (e.g. an edit that fails once and is retried — even easier: any parallel tool batch in two consecutive steps).
2. Reload the web UI for that session (or click "Load earlier").
3. Chat view shows the red Failed to load history … received more than one start Match banner and renders only the stale tail; Trajectory view is unaffected.

[claudejaune]

I'm facing the same issue

[xiaoshenming]

对，这是 Web Chat 折叠，不是 session.jsonl.zstd 坏了。9:tool-calledit0 / 9:tool-callread:0 来自 conversationContextKey("tool-call", id)：两次 tool/call 共用 edit:0 / read:0（模型按「工具名+步进」编号），第二次 start Match 直接抛。Trajectory 还能看、JSONL 完好，也符合。

dsh-session-surgeon 不会给第二次 call 换假 id，也不会删重复 start——result 对不上就会变成悬空 tool_call / 永久 400。inspect health 若是 ok，apply 不会改文件，也救不了 Chat 红条。

要恢复聊天只能：用 Trajectory、开新会话（⋯ → 复制会话 ID 贴过去接着学），或等官方 matcher 把同 id 的第二次 start 当 update / 拒绝写入 read:0 这种 id。

[lolicin]

Same root cause here. Wanted to add data on which setups trigger it, because I think it narrows where the fix belongs.

I scanned 13 session logs under ~/.dsh/sessions, counting tool/call events against distinct callIds:

gateway (provider)	model	tool calls	distinct IDs
ify	deepseek-v4-pro-0813	46	46
ify	deepseek-v4-pro-0813	59	59
ify	deepseek-v4-pro-0813	63	63
deepseek-official	deepseek-v4-flash	130	130
deepseek-official	deepseek-v4-flash	35	35
ify0d00	kimi-k3	122	122
oct	kimi-k3	48	11
oct	kimi-k3	12	4
oct	kimi-k3	64	2

The rows that matter are the kimi-k3 block: the same model is fine behind one gateway and broken behind another. ify0d00 passes random IDs through (call_0058dbadc7424aaf9a103a6a); oct doesn't, so the normalization layer falls back to <toolname>:<index> (rw_exec:0, grep:1), where the index restarts at 0 on every assistant response.

So this isn't model behavior — it's that dsh has no fallback for a gateway that omits tool_call.id:

• Producer (LLM normalization layer): synthesizes <name>:<index>, unique only within one response.
• Consumer (conversationContextKey(kind, id) in dsh-client-runtime): keys contexts by kind + callId and allows exactly one start Match, throwing fail-loud otherwise (acceptMatch, client.js:6543 / 6615).

Nothing in between promotes the ID to session-global uniqueness, so the contract breaks.

Two more observations that may help:

1. This is not reload-only. The first collision in my session is seq=1620 (turn 4, step 1) against seq=112 (turn 1, step 2) — long before the session ends at turn 15 / 79 steps. appendLive (streaming) and replaceWindow (reload) both funnel into the same acceptMatch, and the streaming path has no try/catch, so the conversation view degrades early and only becomes obvious on reload. That matches the "only one message renders" symptom people report.

2. Re: the concern above that rewriting IDs creates dangling tool_calls — that only happens if you rewrite tool/call without the matching tool/result. I patched my log by renaming consistently within each (turn, step) (call / result / assistant-message content all together) and verified 64/64 pairing: no dangling calls, no orphan results. So it's a viable local workaround, obviously not a fix.

Suggested fix: either scope the context key by turn/step, or have the normalization layer mint globally unique IDs when the gateway doesn't supply one.

[liyangbing]

这个复现已经把 provider/gateway 的 ID 生成与 Web Chat replay 的严格 matcher 两层区分出来了。恢复时建议把原始 Session 当作只读证据，不要为了让 Chat 能加载而直接重编号或删除 tool/call：

• 先复制并哈希原始 JSONL/zstd、记录 DSH revision、provider/model、事件序列和首个重复 callId；
• 用 Trajectory 或只读 extractor 继续查看完整工作轨迹，把 Chat 展示失败标为 projection/replay failure，而不是 Session 文件损坏；
• 若要做临时兼容投影，在新 artifact 中成对变换 tool/call、tool/result、assistant message source 和引用，保留原始 seq、source、provider ID 与变换映射；绝不能把投影覆盖回生产 Session；
• 验证重复、缺失 result、跨 turn/step 重复、并行调用、截断尾部和重启后的冷回放，并确认健康 Sessions 不被一个坏 projection 拖垮；
• 上游修复应选择清晰的所有权：在 LLM 边界生成 session-unique ID，或让 Chat context key 包含 turn/step；若只能降级，按 context 隔离并给出可见诊断，不能静默丢掉后续历史。

如果 issue 作者补充 provider/gateway 的原始 tool-call ID 是否为空、何时被合成，以及 call/result 成对映射，会更容易决定修复位置。独立社区手册的 Session 完整性与展示投影边界：https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/session-history-corruption-triage.md 。手册不是 DeepSeek AI 官方项目。