Bug: every tool call fails with unknown tool "" when gateway sends explicit null id/name on tool-call deltas

[realchendahuang]

Summary

Every tool call fails with ToolNotFoundError: unknown tool "" (empty tool name) when the DeepSeek API is reached through a gateway/proxy that sends explicit nulls on tool-call continuation frames. Reproduced with baseURL: https://opencode.ai/zen/go/v1 + deepseek-v4-flash on 0.1.0-rc.6 (bug also present in rc.7 — I diffed the translate code).

The official https://api.deepseek.com endpoint is unaffected (it omits the fields entirely), so this only bites users behind third-party gateways.

Symptom / log signature

Session log (session.jsonl) — the first delta carries the call identity, every continuation frame clobbers it:

{"type":"tool-call-delta","index":2,"id":"call_b72f0fa7...","name":"bash","argumentsDelta":""}
{"type":"tool-call-delta","index":2,"id":"","name":null,"argumentsDelta":"{"}
{"type":"tool-call-delta","index":2,"id":"","name":null,"argumentsDelta":"\"command\": \"pwd && echo"}

Final assembled block: {"type":"tool-call","id":"","name":"","arguments":"..."} → tool executor looks up tool "" → ToolNotFoundError: unknown tool "" → the model retries the same failing call every step and eventually gives up (its reasoning even starts hallucinating <invoke name=""> XML — a red herring, the protocol is structured tool_calls).

Root cause

translate() in packages/llm/llm-deepseek/src/translate.ts guards the accumulated call identity with !== undefined:

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

The standard OpenAI-compatible stream contract omits id/name on continuation frames, but some gateways send them as explicit null. Since null !== undefined is true, each continuation frame overwrites the accumulated callId/name with null → every subsequent delta carries id: "" / name: null → final block has empty name.

Suggested fix (2 lines + regression test)

Use != null so both undefined and null are rejected:

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

I verified: with the exact wire shape from the failing session, the old code reproduces the empty id/name byte-for-byte; the new code preserves the identity across the stream, and the tool call executes normally.

I have a prepared branch with the fix + a regression test in tests/translate.spec.ts (31/31 tests pass): https://github.com/realchendahuang/deepseek-harness/tree/fix/null-tool-call-deltas

Since external PRs are not accepted yet, happy for maintainers to cherry-pick from that branch, or I can apply any changes you'd prefer.

Workaround for affected users (until fixed)

Patch the two lines in the installed package and restart dsh:

sed -i '' 's/if (call.id !== void 0) block.callId = call.id;/if (call.id != null) block.callId = call.id;/; s/if (call.function?.name !== void 0) block.name = call.function.name;/if (call.function?.name != null) block.name = call.function.name;/' \
  ~/.dsh/profiles/node_modules/@deepseek-ai/dsh-llm-deepseek/lib/index.js

(Linux: drop the quotes after -i. Note: re-apply after upgrades.)

[qiweiz94]

Confirmed the same root cause on the same gateway shape (baseURL → OpenAI-compatible chat-completions, deepseek-v4-flash). The !== undefined guards in translate() admit "" and null on continuation deltas, so the first chunk's captured id/name get overwritten and the assembled call collapses to unknown tool "" — and the empty callId then persists into the session log, which on reload fails the assertMessageEventShape tool-source check (callId === ''), bricking the whole session's history.

I applied a fix that treats empty as absent and guarantees a non-empty fallback id at every site where a tool-call block is assembled:

• packages/llm/llm-deepseek/src/translate.ts — keep the first-present id/name (only assign non-empty strings); fall back to call-<index> at both the delta emit and closeBlock
• packages/llm/llm-pi-ai/src/stream.ts — same non-empty fallback on toolcall_start/toolcall_delta/toolcall_end
• packages/llm/llm/src/assembler.ts — || instead of ?? so an explicit empty string also falls back to call-<index> instead of surviving into the log

Tests: updated the two cases that previously asserted the empty-id output, added a regression for the explicit empty-string delta, full llm suite passes (818 tests). The call-<index> fallback is locally unique per message, so it also avoids the duplicate-tool_call_id rejection downstream.

Cherry-pickable single commit on master: bfe2def354
(fork: qiweiz94/deepseek-harness, base = current upstream master)