Bug: tool calls lose their name/id when streamed through OpenAI-compatible gateways (empty-string deltas overwrite assembly)

[fengcunhan]

Symptom

Running dsh-llm-deepseek@0.1.0-rc.7 against an OpenAI-compatible gateway (a New-API deployment, DEEPSEEK_BASE_URL pointed at it) breaks every tool-using turn: the assembled tool call ends with name: '', dispatch fails on the unknown empty name, and the turn dies after its first call — with a well-formed wire stream and no adapter error.

Root cause

The official DeepSeek API sends a tool call's id/function.name only on the opening chunk and omits both fields from argument-delta chunks. Gateways instead pad them with empty strings on every delta (captured 2026-08-18 against deepseek-v4-flash-0731):

{"delta":{"tool_calls":[{"index":0,"id":"call_x","type":"function","function":{"name":"bash","arguments":""}}]}}
{"delta":{"tool_calls":[{"index":0,"id":"","type":"function","function":{"name":"","arguments":"{\"command\""}}]}}

translate.ts treats any present field as authoritative:

if (call.id !== undefined) block.callId = call.id
if (call.function?.name !== undefined) block.name = call.function.name

so each argument delta overwrites the assembled identity with ''.

Fix

An empty-string identity never names a call — both guards should ignore '' exactly like an absent field. Since PRs are disabled on this repository, the complete fix (two-line guard + regression test pinning the gateway capture shape + Agent Note with zh pair, all repo gates passing) is on this branch:

master...fengcunhan:deepseek-harness:fix/llm-deepseek-gateway-empty-tool-identity

Verified end to end against the real gateway with the guard patched into 0.1.0-rc.7 via pnpm patch: bash/read calls assemble and dispatch correctly; unpatched, the same turn fails as described. Happy to adjust anything if a maintainer wants to pull it in.

[ShanguanLinG]

Additional data point: the null variant (opencode.ai gateway)

Confirming this is the same root cause, and reporting a second variant of the placeholder that the guard must also ignore.

Symptom (two independent instances, today)

Every tool-using turn fails with name: '' / Error: unknown tool "" (ToolNotFoundError, code UNKNOWN_TOOL), across two separate sessions whose llm-deepseek.baseURL is pointed at a gateway (this instance: https://opencode.ai/zen/go/v1, model deepseek-v4-flash). Arguments assemble correctly; only the tool identity (name + id) is empty.

Wire capture differences

The original report observed empty-string placeholders (id: "", name: "") from a New-API deployment. Against the opencode.ai relay (https://opencode.ai/zen/go/v1, deepseek-v4-flash), the placeholders come back as null, not "":

{"delta":{"tool_calls":[{"index":0,"id":"chatcmpl-tool-949fba45f1c03816","type":"function","function":{"name":"bash","arguments":""}}]}}
{"delta":{"tool_calls":[{"index":0,"id":null,"type":null,"function":{"name":null,"arguments":""}}]}}
{"delta":{"tool_calls":[{"index":0,"id":null,"type":null,"function":{"name":null,"arguments":"{\"command\":\"pwd\"}"}}]}}

The id/name appear only on the opening delta; every argument delta carries null for both.

Why the current guard misses both

The guard as written treats any present field as authoritative:

if (call.id !== undefined) block.callId = call.id
if (call.function?.name !== undefined) block.name = call.function.name

null !== undefined and "" !== undefined are both true, so either placeholder overwrites the assembled identity with an unusable value.

Suggested fix — cover all three placeholders

Ignore null, undefined, and "" in one guard:

if (call.id != null && call.id !== "") block.callId = call.id
if (call.function?.name != null && call.function.name !== "") block.name = call.function.name

(or a String(value).length > 0 style check). This single change covers both the "" and null gateway variants plus the spec-correct "omitted field" case.

Local verification

Patched into 0.1.0-rc.7 (both the global install and the profile/node_modules copy), then:

• replayed the exact captured delta sequence through the adapter's translate() accumulation logic: unpatched → id:'' name:''; patched → id:'chatcmpl-tool-949fba45f1c03816' name:'bash'
• node --check passes on the patched file

So this is a straightforward, safe hardening of the same guard; it complements (rather than duplicates) #3090's finding. Happy to provide the full patched diff if useful.

[joe1chief]

Thanks for isolating this. I independently reproduced the user-visible function.name failure on @deepseek-ai/dsh@0.1.0-rc.7 and current master (99f6f02): native tool calls fail as UNKNOWN_TOOL: unknown tool "", and repeated headless retries can finally surface as EMPTY_RESPONSE.

I prepared a minimal, tested implementation that covers both continuation placeholder variants in one regression case:

{ index: 0, id: 'call_00_x', function: { name: 'get_weather', arguments: '' } }
{ index: 0, function: { name: null, arguments: '{"city"' } }
{ index: 0, function: { name: '', arguments: ': "Paris"}' } }

The current assignment fails the test because the emitted delta names become null, then "", and the final block name becomes "". The fix only accepts a non-empty string as an accumulated name update:

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

It also models the observed wire shape as name?: string | null.

Tested commit (one commit directly on the referenced master revision):

• commit: joe1chief@0483330
• branch: https://github.com/joe1chief/deepseek-harness/tree/agent/preserve-streamed-tool-name

Verification completed:

• focused translator spec: 30/30 passed
• selected translate.ts coverage: 100% statements, branches, functions, and lines
• package tsc -b: passed
• pnpm run doc-sync: 28/28 gates passed
• full pnpm run lint: passed
• repository pre-commit hooks: passed

This commit deliberately scopes itself to function.name, which is the value that causes UNKNOWN_TOOL. The same non-empty-string rule can also be applied to call.id when adopting the broader identity fix discussed above.

[weijiafu14]

A measured A/B for exactly the delta shapes you isolated, from the other accumulator in this ecosystem.

We fault-injected the real pi-ai 0.84.1 openai-completions client/parser/accumulator (only the wire bytes are synthetic) with the gateway shapes from your report: continuation deltas carrying empty-string id/name, identity arriving late, two parallel calls with no ids at all (index-keyed interleave), and id-keyed deltas with no index. All of them assemble correctly — pi-ai keys blocks by index first and lets the first non-empty id/name win, so the empty-string-overwrite path your diagnosis found in dsh-llm-deepseek structurally does not exist there. Per-case verdicts: accumulator-experiment.mjs / results, re-verified on latest 0.84.4.

Live confirmation on a real upstream: through pi2dsh (stock @deepseek-ai/dsh@0.1.1-rc.2, official llm-pi-ai route, transparent recording proxy → api.deepseek.com), a two-tool-call turn executed with distinct non-empty call ids and a 43-record history that parses and reloads clean (case parallel-calls in provider-threads-e2e.json).

Scope honesty: this is a parallel-path datapoint, not a fix for dsh-llm-deepseek — your three empty-value paths in that adapter still deserve the patch you proposed. One caveat on the other path: markdown-fenced arguments DO break pi-ai's accumulator (silent {}), filed upstream as earendil-works/pi#8858.