Bug + one-line fix: streaming tool calls lose function.name when continuation chunks send name: null (dsh-llm-deepseek, rc.6)

[Xreative]

Streaming tool calls lose function.name when continuation chunks send name: null

Package: @deepseek-ai/dsh-llm-deepseek (also affects @deepseek-ai/dsh) · Version: 0.1.0-rc.6
Repo path: packages/llm/llm-deepseek/.../index.js

Summary

Every tool call made by the model is rejected at dispatch with unknown tool "" when the
LLM is reached over an OpenAI-compatible streaming chat-completions endpoint whose
continuation chunks include function.name: null (a valid, common variant of the OpenAI
streaming tool-call protocol — the name is sent once in the first chunk, then null while
the arguments stream).

Root cause

In the SSE tool-call accumulator:

for (const call of delta?.tool_calls ?? []) {
    let block = toolBlocks.get(call.index);
    if (!block) { /* open block */ }
    if (call.id !== void 0) block.callId = call.id;
    if (call.function?.name !== void 0) block.name = call.function.name;   // <-- bug
    const fragment = call.function?.arguments ?? "";
    block.text += fragment;
    ...
}

The guard call.function?.name !== void 0 only skips undefined. When the provider streams
function.name: null in continuation chunks (after the first chunk carried the real name),
null !== undefined is true, so block.name is overwritten with null. At
finalization name: block.name ?? "" collapses to "", and the runtime then rejects the
call as unknown tool "".

Observed stream (first chunk has the name, rest send name: null):

delta.tool_calls[0].function = { "name": "write_file", "arguments": "" }
delta.tool_calls[0].function = { "name": null, "arguments": "{" }
delta.tool_calls[0].function = { "name": null, "arguments": "\"path" }
...

Non-streaming responses from the same endpoint return the complete function.name, so the
defect is specific to the streaming accumulator.

Fix (one line)

Guard against null as well as undefined:

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

(!= null matches both null and undefined.) The same care should be applied to the
tool-call-delta emit that follows, so a later null never blanks a previously known name.

Impact

Tool use is completely broken for any OpenAI-compatible provider that emits name: null on
continuation chunks — the agent can never call write/bash/fs/etc. Confirmed fix
restores tool use (verified end-to-end: model created a file via its file tool).

[argszero]

This is the same bug already reported on #1713 (BehindTheCartan, SGLang) — your one-line fix is exactly right, and I verified it line-by-line against master (47f9438) when that thread was open. Worth converging the two threads so the fix lands once.

Confirmation (current master):

• translate.ts:159-160: if (call.id !== undefined) block.callId = call.id / if (call.function?.name !== undefined) block.name = call.function.name — an explicit null from a continuation chunk satisfies !== undefined and overwrites the first-chunk-captured values.
• Downstream collapse: :166 CallId(block.callId ?? '') + :167 ...block.name !== undefined ? { name: block.name } : {} turn the null into ''/absent → dispatch sees unknown tool "" → UNKNOWN_TOOL.
• arguments is unaffected (:161 ?? '' → null is a no-op append), which is why only id/name break.

The fix (both threads agree):

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

plus :167 → ...block.name != null ? { name: block.name } : {} for defense.

One thing both reports missed: the regression-test gap in translate.spec.ts:105-107 — the existing cases cover the DeepSeek-official omission convention (continuation deltas simply omit id/name) but not the explicit-null convention (SGLang and others repeat the fields as null). A test case modeled on your wire shape fails on current code and passes after the fix — that's the proof a maintainer will want alongside the two lines.

Details (reachable surface, scope, lint) are in my #1713 reply: #1713 (comment). If you have the wire capture handy, adding it to #1713 would give the maintainers a single thread with both provider samples.

[zoahdev]

Shipped with the regression that closes the test gap @argszero flagged.

• Branch: zoahdev/deepseek-harness@fix/llm-deepseek-toolcall-null-name (cherry-pick-ready against 47f943859b).
• packages/llm/llm-deepseek/src/translate.ts: id and name accumulation now use != null, and the emitted tool-call-delta name guard matches, so an explicit null on a continuation chunk never blanks the first-chunk value.
• New test models the explicit-null wire shape (first chunk carries id/name, continuations repeat them as null); translate.spec 31/31 green. It fails on the old !== undefined guard and passes after.

Agree this converges with #1713 — same two lines, now with the regression test in place. If the maintainers want one PR, the test belongs here regardless of which thread carries the patch.