[Bug] Web Chat/Trajectory view stops mid-session when tool call ids repeat across steps | 工具调用ID跨step重复导致对话视图卡死

[Yikanji]

中文摘要

长会话历史重放到 Web 对话/轨迹视图时，前端组装崩溃，对话流停在某个 step 后所有后续 turn 都不显示。原因是工具调用 ID（callId）在每个 step 内从 0 重新计数，跨 step 重复，ConversationNodeAssembler.acceptMatch 对同一 tool-call context 的第二个 start 抛 received more than one start Match，中断整个窗口的节点构建。与 #5732 同根因（tool call id 不唯一），但表现为客户端视图卡死而非 provider 400。

English

Reproduction

A 9-turn / 90-step session. Tool call ids restart from zero within each step, so the same id (e.g. ssh_exec:0) appears in two different steps (step 40 and step 42).

Replaying the session into the Chat or Trajectory view throws:

复制
conversation Context 9:tool-callssh_exec:0 received more than one start Match
The exception aborts replaceWindow: the flow stops at the offending step and every later turn (6–9) is missing, while session stats stay correct.

Root cause direction

Same as #5732: model-produced tool call ids are not unique. Here it breaks DSH's own view assembly instead of a strict provider. Not limited to Ollama — also reproduced with hcnsec/kimi (OpenAI-compatible).

[argszero]

Good report — I verified the source exactly as you described, and this is the client-side view-assembly manifestation of the same non-unique tool-call-id root as #5732. Confirming the mechanism and mapping the fix surface.

Source confirmation. The error comes from packages/client/ui-conversation/src/client/conversation/assembler.ts in acceptMatch (line 513) and applyPendingMatches (line 569):

throw new Error(`conversation Context ${key} received more than one start Match`)

The context key is conversationContextKey(definition.kind, id) (contract/conversation.ts:295), which is ${kind}:${id} — keyed solely on (kind, id) with no step/seq disambiguation. So when the model reuses a tool-call id across two steps (e.g. ssh_exec:0 at step 40 and step 42), the same (kind, id) context receives a second start, context.start !== undefined is true, and the throw aborts replaceWindow — which is why the flow stops at the offending step and everything after it (turns 6–9) goes missing while session stats stay correct.

Root cause = model-produced tool-call ids are not unique. Same as #5732 (which fails a strict provider) and #5413/#5247/#5268 in the same family. Here the failure surfaces on the view side because the assembler assumes (kind, id) is a unique identity per run.

Where the fix belongs (two candidate surfaces):

1. Assembler (client view layer) — the cheap, self-contained fix: disambiguate the Context key by the event's step/seq, so a repeated id in a different step creates a distinct context instead of colliding. e.g. scope by (kind, id, stepSeq) or namespace the key with the run's step range. This keeps replayed history renderable even when the producer emitted duplicate ids.
2. Id generation (producer side) — the deeper fix (and the one Tool call IDs from model not unique across turns; duplicates break strict providers (400) #5732 points at): make the tool-call id globally unique per run rather than per-step. That's the correct semantic fix, but it's a wire/contract change that touches persisted sessions and replays, so it can't fix already-released sessions that carry duplicate ids. Assembly would still need to tolerate them.

Realistically both are needed, but #1 is the right first move — it's the defensive layer that makes long-history replays robust to the data that already exists in the wild. #2 prevents the bad data going forward. I'd file #1 as a UI/assemble bug with #2 as the production-side root fix.

I can draft the #1 fix (scope the Context key by step) and verify it against conversation-assembler.client.spec.ts (which already asserts the throw at line 1538) if useful — happy to open a PR if that's welcome.

[Yikanji]

Thanks for the thorough verification and the clean split between #1 (assembly) and #2 (production). I agree #1 is the right first step.

I already have a local client-side fix that stops the crash — it lets a repeated start re-adopt the tool-call context instead of aborting the window. It resolved the real session (turns 6–9 render again) and 802 tests pass. But re-reading it against your note, my version uses last-writer-wins and drops the earlier step's call rather than keeping each occurrence — so it's a stop-the-crash fix, not a clean scoping one.

Your #1 (scoping the context key by step/seq) is strictly better: it preserves both occurrences. I'll rework my local fix to match that direction, verify it against the same session, and can share the updated diff for your review. Happy to help validate if you open the PR.