Streamed tool-call deltas with null id/name break tool calls (ToolNotFoundError loop)

[JohnXu22786]

dsh 0.1.1-rc.2, Windows 11, @deepseek-ai/dsh-llm-deepseek.

Any task that needs a tool call fails: the agent emits tool/call with an empty name, the harness answers ToolNotFoundError (UNKNOWN_TOOL), and it loops the same call until it gives up. The final turn still reports reason.kind = "completed", so headless exits 0 with no output — looks like success.

Root cause is in dsh-llm-deepseek/lib/index.js (lines ~1063-1064):

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

With streamed deltas, the first chunk carries the correct id/name, and later chunks carry "id": null / "name": null (the OpenAI streaming convention for "no update"). Those pass the !== void 0 check and overwrite the real values; closeBlock then resolves name ?? "" to "".

Verified on a capture: the upstream response contains "name":"pwsh" correctly; the merged block ends up {"type":"tool-call","id":"","name":"","arguments":"..."}.

Fix (tested locally):

if (typeof call.id === "string") block.callId = call.id;
if (typeof call.function?.name === "string") block.name = call.function.name;

Only check for string, ignore null/undefined.

[argszero]

Verified against rc.2 (HEAD b150a55) — the source matches your built lib/index.js citations exactly, and this thread is the 10th report of the wire identity-loss family, the 5th instance of the explicit-null class. One refinement to your fix is important, plus one observability point I want to flag separately.

Family convergence: 5th instance of the explicit-null class

Your trace is the exact mechanism of #1713 (SGLang) → #2090 (Xreative) → #2997 (opencode.ai zen) → #4265 (opencode.ai/zen/go/v1 relay) → yours: the first delta captures the correct id/name, later "no update" frames send null, and !== undefined (translate.ts:159-160) lets null overwrite the captured values. rc.2 confirmation:

• translate.ts:159 if (call.id !== undefined) block.callId = call.id — null !== undefined is true → overwrite
• translate.ts:160 if (call.function?.name !== undefined) block.name = call.function.name — same
• assembler.ts:70 partial.toolCallId = chunk.id — unconditional, the id/name asymmetry the family has flagged since Bug: tool-call id/name overwritten by empty strings from OpenAI-compatible providers (every tool call becomes `unknown tool ""`) #2540 (:71 name has a truthy guard, :70 id never got one)

The refinement: typeof === "string" still accepts "" — use truthy

Your fix is a strict improvement over !== undefined (it covers null), but it has the exact same blind spot the family paid for twice: typeof "" === "string" is true. The empty-string variant is not a recoverable per-turn loop — it is the permanent poison: an empty callId persisted into tool/result makes the session unloadable (packages/core/session/src/index.ts:340-341 throws "message must have tool source" for callId === ''), the severity documented on #2169 and reconfirmed on #2540 and yesterday's #4365 (official DeepSeek gateway sent id:"" in the final delta frame). So the family-complete guard is truthy on both fields:

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

covers missing / null / "" in one form. (The #1713-family threads converged on this exact shape; two earlier patches used != null and missed "" — the regression matrix must include all three states.)

L2 still applies: assembler.ts:70

Your fix is translate-only, like the earlier patches. BlockAssembler is shared by ALL provider adapters (packages/llm/llm/src/assembler.ts), and partial.toolCallId = chunk.id at :70 remains an unconditional overwrite with no truthy guard while :71 has one. If you submit a PR, mirroring if (chunk.id) at :70 closes the class for non-llm-deepseek adapters too, and a three-state regression (missing / null / "" deltas) at the assembler level covers the delta-accumulation fallback path.

Separately: "reason.kind = completed + headless exit 0" is a real observability gap

Your last observation deserves its own thread: after the ToolNotFoundError loop gives up, the turn still reports reason.kind = "completed" and headless exits 0 — a failed agent run presented as success. That is a turn-reason accuracy issue independent of the wire bug: a tool chain that errored to exhaustion should surface as error (or at least a non-zero headless exit), not completed. The wire fix stops the loop; it does not stop the silent-success masking. Worth reporting separately so it gets its own fix rather than riding along.

Full family state: 9 reports / 12 threads before yours (#1449/#1519/#1337/#1593/#1713/#2090/#2169/#2343/#2540/#2855/#2997/#4265/#4365), now 10 reports / 13 threads. One canonical patch closes the class: L1 truthy guards in translate (id + name) · L2 if (chunk.id) at assembler.ts:70 · L3 assemble() backfill · L4 closeBlock source-side fallback (#4365) · three-state regression matrix.

[JohnXu22786]

Thanks for the detail. I've updated the local patch to truthy guards on both fields and re-verified the tool flow. Will post the silent-success (completed + exit 0) issue as its own thread.