[Bug] Tool-call name dropped when gateway streams explicit "null" name deltas (dsh-llm-deepseek)

[zszsz2424-rgb]

Bug: Tool-call name is dropped when the provider streams explicit "name": null deltas

Summary

When using an OpenAI-compatible gateway (not the official api.deepseek.com) as llm-deepseek.baseURL, every tool call loses its function name (name becomes empty). The harness then fails every tool invocation with Error: unknown tool "", and agents loop/retry until they exhaust. Simple no-tool conversations work fine.

Environment

• @deepseek-ai/dsh 0.1.0-rc.6 (also verified on 0.1.0-rc.7 — same code path)
• Component: @deepseek-ai/dsh-llm-deepseek
• Model: deepseek-v4-flash (also observable with deepseek-v4-pro)
• Gateway: https://opencode.ai/zen/go/v1 (OpenAI-compatible chat/completions), streaming with stream_options.include_usage=true
• Host: Windows 11, Node 24

Repro

1. Configure llm-deepseek.baseURL to any OpenAI-compatible gateway that emits the standard streaming shape shown below.
2. Ask the agent to perform any task that requires a tool (e.g. "list files with the glob tool").
3. Observe: the first tool call is recorded with name: "" and the tool layer returns Error: unknown tool "". The model retries and typically fails the whole task.

Root cause

In @deepseek-ai/dsh-llm-deepseek/lib/index.js (translate), the tool-call name is applied with:

if (call.function?.name !== void 0) block.name = call.function.name;

In JavaScript, null !== void 0 evaluates to true. OpenAI-compatible gateways emit the first streaming delta with the real name, then subsequent deltas with explicit null for id/name (standard shape). Those subsequent deltas overwrite the captured name with null, and closeBlock then flattens it to "".

The official DeepSeek API does not send the explicit null (it omits the fields entirely), so this bug is invisible against api.deepseek.com and only appears when a gateway sends the protocol-standard null.

Wire evidence

Streaming deltas received from the gateway (real trace):

// delta 1 — has the name
{"tool_calls":[{"index":0,"id":"call_40845b447d9444578534e12d","type":"function","function":{"name":"glob","arguments":""}}]}
// delta 2+ — explicit nulls overwrite it
{"tool_calls":[{"index":0,"id":null,"type":"function","function":{"name":null,"arguments":"{"}}]}
{"tool_calls":[{"index":0,"id":null,"type":"function","function":{"name":null,"arguments":"\"pattern\": \"*\""}}]}

After the patch below, the same task succeeds: name: "glob", output completed with correct file count.

Suggested fix

Only overwrite when name is a non-empty string:

if (typeof call.function?.name === "string" && call.function.name.length > 0) block.name = call.function.name;

Equivalent guards are used elsewhere in the file for call.id and for reasoning_content/content. The same !== void 0 pattern on a nullable field is a latent bug for any gateway that serializes nulls.

Notes

• Applying this one-line fix locally resolves the issue end-to-end (verified: tool calls execute, task completes).
• Happy to open a PR if maintainers prefer that path — the fix also needs to land in dsh-llm-deepseek for both the web and headless profiles.

[argszero]

Verified against rc.7 (99f6f02fec) — your root cause is exactly right, and the source shows the fix is incomplete as written: the identical !== void 0 pattern sits one line above on call.id, and your own wire trace contains the "id": null delta that trips it.

1. Confirmed at source. translate (packages/llm/llm-deepseek/src/translate.ts):

• :159 if (call.id !== undefined) block.callId = call.id
• :160 if (call.function?.name !== undefined) block.name = call.function.name
• closeBlock (:69-74) then flattens: id: CallId(block.callId ?? ''), name: block.name ?? ''.

null !== undefined is true, so a protocol-standard "name": null (and "id": null) overwrites the captured value, and closeBlock degrades it to ''. The official DeepSeek API omits the fields entirely, so the bug is invisible against it — exactly as you observed.

2. Your fix is incomplete — call.id has the same bug and your trace proves it. Your delta evidence shows {"index":0,"id":null,...} in delta 2+. So block.callId is also nulled, and closeBlock emits CallId('') — an empty tool-call id. Your one-line name patch fixed the visible unknown tool "" symptom, but the empty id remains on every tool call through that gateway. Two reasons it didn't bite in your test: the tool layer resolves by name, and empty ids are internally consistent (assistant tool-call id '' → tool/call '' → tool/result ''), so the turn completes. But an empty tool_call_id is exactly the shape the wire-serializer family has been hunting (see below) — it will 400 on providers that validate id presence, and it breaks replay/UI tool-call correlation. The durable fix must guard both fields:

if (typeof call.id === 'string' && call.id.length > 0) block.callId = call.id
if (typeof call.function?.name === 'string' && call.function.name.length > 0) block.name = call.function.name

3. The design intent is "first non-null wins" — and the assembler already implements it for name but not id. BlockAssembler.push (packages/llm/llm/src/assembler.ts): :70 partial.toolCallId = chunk.id (unconditional overwrite) vs :71 if (chunk.name) partial.toolCallName = chunk.name (truthy guard — keeps the first name). The name guard dates to June 11 (d5a1d9bb759) and predates the recent wire-family fixes; the id guard was never added. So even a translate-level fix is only half the defense: any future translator that emits a null/empty id in a later delta would still clobber it at the assembler. Align :70 with :71 (if (chunk.id) partial.toolCallId = chunk.id), and your translate fix becomes belt-and-braces.

4. One more surface in the same delta emission. translate.ts:167 ...block.name !== undefined ? { name: block.name } : {} — with block.name = null, this emits name: null into every tool-call-delta (the assembler tolerates it via the truthy guard, but other consumers of the delta stream won't necessarily). The non-empty-string guard on the assignment fixes this transitively.

5. Family connection. This is a new trigger class in the serializer/wire family (the "explicit-null-overwrite" class, complementing the lone-surrogate/malformed-arguments poisoning class): the same !== undefined pattern on nullable stream fields, and it happens on the inbound translate path while the family's prior fixes (#1449/#1519, serialize.ts) guarded the outbound path. Notably, the family's fix blueprint already includes an "assembler id guard" — this report is an independent confirmation that the guard is needed. Your end-to-end verification plus the wire trace makes this a one-PR-sized fix (translate.ts two guards + assembler.ts id guard + a regression test feeding the three-delta shape you captured).

Good catch — and thanks for including the raw deltas; that's what made it verifiable in one pass.

[argszero]

Correction/addendum to my comment above — this is actually the third independent report of this exact mechanism, not a new class: #1713 (BehindTheCartan, SGLang endpoint) and #2090 (Xreative, another gateway) documented the identical explicit-null-delta overwrite with the same root cause (!== void 0 at translate.ts:159-160). Three providers now exhibit it: SGLang, Xreative's gateway, and your opencode.ai one — which means the "official API omits the fields" invisibility argument generalizes: any OpenAI-compatible gateway that serializes nulls hits this.

For convergence: #1713's analysis already included the :159 id fix (!= null on both lines + :167 defense), which covers the "your one-line fix is incomplete" point from my comment. What's still missing from all three threads is the assembler-side guard (assembler.ts:70 overwrites toolCallId unconditionally while :71 guards name) — that's the one genuinely new addition. Merging all three wire captures (SGLang / Xreative / opencode.ai) into one PR candidate would give maintainers three provider samples for one regression test. Your end-to-end verification is the strongest of the three — thanks for the raw deltas.