Tool call IDs from model not unique across turns; duplicates break strict providers (400)

[lmznhq]

Environment: dsh 0.1.3-alpha.1 (@deepseek-ai/dsh-root), local, tool-calling agent sessions

Problem: the upstream model returned the same tool_call id in two different turns of one session (id call_77177: assistant turn N = bash, ~30 messages later = read). DSH stores model-provided tool call ids verbatim (packages/llm/llm/src/message.ts:238 toolCallId: input.callId; assembled at assembler.ts:115) with no session-wide uniqueness guarantee. When such history is later forwarded to a strict provider that enforces unique tool_call_id (in our setup AIClient2API -> Google Antigravity), the request is rejected:

400 {"error":{"code":400,"status":"INVALID_ARGUMENT","message":"Request contains an invalid argument"}}

and the whole session becomes unusable (every follow-up re-sends the same history).

Evidence: session history contains call_77177 twice (assistant msg #7 bash, msg #37 read). The fallback at assembler.ts:115 (call-${index}) is not the source - the duplicate came verbatim from the model response. This differs from the known Ollama case (yuanc1204/dsh-ollama-tool-call-id-fix) where an adapter reuses call_0 per request; here the model itself occasionally emits a repeated id.

Suggested fix: guarantee tool-call ids are unique across the session when appending assistant tool_calls to history (and/or when serializing history for external providers): on a repeated id, rewrite the later occurrence to a fresh id and remap the matching tool message's tool_call_id. A rewrite point near history append (e.g. where message.ts builds the message) or in the external serializer would cover all providers. DSH-internal consumers of its own endpoint never notice duplicates, which is why this only surfaces through strict relays.

Related: #1593 (tool result referencing a missing call id also bricks a session with provider 400s).

[Mide69]

Checked both source claims against current master, both exact.

message.ts:238 is really the verbatim passthrough: toolCallId: input.callId, no transformation. And assembler.ts:115 is really id: partial.toolCallId ?? brandString(call-${index}) — that fallback only fires when the model gives no id at all, so it genuinely can't be the source of a repeated id like you already ruled out. I also grepped the whole llm package tree for anything resembling a uniqueness check on tool call ids (a Set, a dedup pass, anything) and found nothing at all. So "no session-wide uniqueness guarantee" isn't just plausible, it's confirmed by absence.

Worth connecting this to #1593, which argszero investigated in depth: that one is the mirror case, a tool/result referencing a call id that was never emitted at all (orphan result instead of your duplicate/collision). Same underlying gap either way: nothing between history assembly and wire serialization checks that assistant tool_calls and the following tool messages actually correspond one-to-one. argszero's writeup there also names two more related threads (#1449, #1519) covering truncated/replayed tool-call arguments hitting the same seam. Four separate trigger paths into one missing validation is a stronger case for a real fix than any one report alone, might be worth linking your report into that family when raising it.

Your fix direction (rewrite the later duplicate and remap the matching tool message before it reaches serialization) matches the pattern argszero suggested for the orphan case too: catch it at assembly/serialize time with a fail-fast or auto-correct pass, rather than only after a provider round-trips a 400.