Bug: Tool calls fail with unknown tool "" (empty name) when a large tool call is split into multiple stream chunks

[guzhou0102]

Bug: Tool calls fail with unknown tool "" (empty name) when a large tool call is split into multiple stream chunks

Environment

• DeepSeek Harness 0.1.0-rc.6 (npm @deepseek-ai/dsh)
• Provider: deepseek-official route → opencode-go gateway (https://opencode.ai/zen/go/v1), model deepseek-v4-flash
• Agent preset: standard, permission: danger-full-access

Symptom

After a tool call whose arguments are split across many SSE chunks, every subsequent tool call fails with Error: unknown tool "" (ToolNotFoundError, code UNKNOWN_TOOL). This is systemic, not per-tool: bash, grep, read, echo, web_search all fail. Once it starts it never recovers in the same step; the session is effectively dead for tool use.

Root cause (confirmed with raw stream bytes)

In packages/llm/llm/src/assembler.ts (BlockAssembler), two defects combine:

1. tool-call-delta id capture is unconditional — it clobbers the first-captured id:

   partial.toolCallId = chunk.id;                    // unconditional: later empty-id deltas reset it
   if (chunk.name) partial.toolCallName = chunk.name; // guarded — name survives, id does not

   When the gateway emits an empty id on subsequent deltas, partial.toolCallId becomes ''.

2. block-end + assemble() short-circuit discards the accumulated name/id even when they were correctly captured:

   case 'block-end': {
       ...
       partial.block = chunk.block;   // raw block (may carry empty name/id) overwrites
   }
   assemble(partial, index) {
       if (partial.block) return partial.block;  // returns raw block as-is; accumulated deltas ignored
   }

   So even when partial.toolCallName was set correctly, assemble() returns the raw block-end block whose name/id may be empty → ToolNotFoundError: unknown tool "".

Evidence (raw chunks from a failed session)

A failing bash call, same block index, name present on the first delta only, then all-empty id/name; the block-end carries an empty block:

{"type":"assistant/chunk","data":{"chunk":{"type":"tool-call-delta","index":2,"id":"call_2a60dd...","name":"bash","argumentsDelta":""}}}
{"type":"assistant/chunk","data":{"chunk":{"type":"tool-call-delta","index":2,"id":"","name":null,"argumentsDelta":"{"}}}
{"type":"assistant/chunk","data":{"chunk":{"type":"tool-call-delta","index":2,"id":"","name":null,"argumentsDelta":"\"command\": ..."}}}
... many more deltas, all id="" name=null, argumentsDelta only ...
{"type":"assistant/chunk","data":{"chunk":{"type":"block-end","index":2,"block":{"type":"tool-call","name":"","id":"","arguments":"{...full args...}"}}}}

Contrast a healthy call where every delta carries name:

{"type":"assistant/chunk","data":{"chunk":{"type":"tool-call-delta","index":1,"id":"call_00_...","name":"job_list","argumentsDelta":"{}"}}}

Trigger condition

A single tool call whose arguments are split into many stream chunks (large/full-content arguments — e.g. a big file read or long command). The gateway emits name/id only on the first delta; when the (non-deterministic) chunk-split boundary separates the name-bearing delta from the argument deltas, the assembler drops the name. This is why it appears "random" and reproduces across fresh sessions and restarts.

Minimal reproduction

import { BlockAssembler } from '@deepseek-ai/dsh-llm';

// Simulates the gateway's large-tool-call split: first delta carries id+name,
// subsequent deltas carry only arguments (id="", name=null), block-end is empty.
const a = new BlockAssembler();
a.push({ type: 'block-start', index: 0, blockType: 'tool-call' });
a.push({ type: 'tool-call-delta', index: 0, id: 'call_2a60dd', name: 'bash', argumentsDelta: '' });
a.push({ type: 'tool-call-delta', index: 0, id: '', name: null, argumentsDelta: '{"command": "echo hi"}' });
a.push({ type: 'tool-call-delta', index: 0, id: '', name: null, argumentsDelta: '' });
a.push({ type: 'block-end', index: 0, block: { type: 'tool-call', name: '', id: '', arguments: '' } });
console.log(JSON.stringify(a.blocks()));
// Expected: name returns as 'bash' with id and arguments.
// Actual (rc.6): name='' id='' → ToolNotFoundError: unknown tool "".

Suggested fix

Make assemble() treat the accumulated deltas as authoritative for any field the raw block-end block is missing:

assemble(partial, index) {
    if (partial.block) {
        let block = partial.block;
        if (!block.name && partial.toolCallName) block = { ...block, name: partial.toolCallName };
        if (!block.id && partial.toolCallId)     block = { ...block, id: partial.toolCallId };
        if (!block.arguments && partial.toolCallArguments) block = { ...block, arguments: partial.toolCallArguments };
        return block;
    }
    ...
}

and guard the id capture to match name (if (chunk.id) partial.toolCallId = chunk.id;).

The assembler already documents "log the raw chunks for replay fidelity" — the accumulated partial.* values are provably correct here, so backfilling is safe and cannot regress the healthy path (verified: a fully-populated block-end is returned unchanged).

Notes

• Fix verified against the raw failing stream and the minimal repro above (3-field backfill: name, id, arguments).
• rc.7 (0.1.0-rc.7) does not fix this: commit 84257ea changes only max-tokens replay-metadata alignment; assemble() still short-circuits on partial.block.

[argszero]

Verified on rc.7 (99f6f02fec) — both defects are exactly as you describe, and this completes the picture I'd been building across the earlier reports. This is the 7th report in the "unknown tool ''" wire family (#1713 → #2090 → #2169 → #2343 → #2540 → #2855), and yours is the first to nail the assembler-side root cause — the earlier threads all pointed at translate.ts, but the shared BlockAssembler was the residual gap.

1. Your two defects confirm at rc.7 source:

• assembler.ts:70 — partial.toolCallId = chunk.id unconditional; the if (chunk.name) at :71 proves the author intended the guarded pattern. A "" (or null) id on a continuation delta clobbers the first-captured id.
• assembler.ts:78-82 + :100 — block-end stores the raw block verbatim and assemble() returns partial.block without backfilling from the accumulated partial.*. So even with the id captured correctly, a raw block-end carrying id: ""/name: "" wins. The adapter's authoritative-block path then persists the poisoned block.

2. Your backfill fix is the correct third layer. The earlier fixes (translate.ts truthy guards — zoahdev's != null on #2090, lanjie8's commit on #2343/#2540) protect the delta accumulation; your assemble() backfill protects the block-end merge. Both layers are needed: the translate fixes stop the deltas from carrying empty values downstream, but any adapter that emits a raw block-end with empty fields (or a truncation that skips deltas entirely) still poisons the final block through the partial.block short-circuit. Your "fully-populated block-end is returned unchanged" invariant is the right safety property.

3. Cross-thread convergence for the fix. The family now has a complete two-layer fix blueprint:

• Layer 1 (translate.ts): truthy guards if (call.id) / if (call.function?.name) — covers null AND "" (zoahdev's != null misses ""; lanjie8's commit 1e635ed is translate-only).
• Layer 2 (assembler.ts): if (chunk.id) partial.toolCallId = chunk.id at :70 (mirrors :71).
• Layer 3 (assembler.ts): your assemble() backfill of name/id/arguments from partial.* when the raw block-end is missing them.
• Regression test: your minimal repro is ideal — it exercises all three layers and asserts the exact blocks() output. Worth adding null and "" variants (both shapes appear across providers).

4. Session-validation note: the reason this becomes a permanent dead session (not just a dead step) is packages/core/session/src/index.ts:339-347 — a tool/result with empty callId is rejected on reload, so a poisoned call + result pair makes the history unloadable (#2169's escalation). Fixing the assembler prevents the poison from being written in the first place.

Worth posting your repro + fix on #2540 (the empty-string thread with the fullest root-cause writeup) so the maintainers get the complete two-layer picture in one place — or I can cross-link. Either way, the family is now fully diagnosed end-to-end.

[weijiafu14]

There is a source-level alternate route that avoids both the affected DeepSeek translator and its empty block-end identity. A transport-owning Pi provider such as pi-provider-litellm can parse the OpenAI-compatible stream itself, while pi2dsh registers that provider as a native DSH LLM route:

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add pi-provider-litellm
export LITELLM_BASE_URL="<your gateway root URL>"
export LITELLM_API_KEY="<your key>"
# restart dsh and select the LiteLLM route

I audited the complete source path before suggesting this. pi-provider-litellm uses Pi's createProvider with openAICompletionsApi. Pi accumulates calls by tool_calls[].index, appends argument fragments, and only replaces the stored id/name when the incoming value is non-empty. A later id: "" or name: null therefore cannot erase the first valid identity. pi2dsh detects the provider's streamSimple, wraps it through llm.registerAdapter, and carries the finalized identity into DSH's tool block.

I do not have your gateway deployment or subscription, so this is source-audited rather than an account-level E2E claim. If you try it and still reproduce the failure, please post a redacted stream/error at https://github.com/weijiafu14/pi2dsh/issues and I will follow the real response shape through the bridge.

[jmche]

Confirming this still reproduces on the current published build, and the root cause is unchanged at master.

Environment

• @deepseek-ai/dsh 0.1.1-rc.2 (npm install)
• Provider deepseek-official, model ap/deepseek-v4-flash, agent preset standard, policy danger-full-access
• Symptom: every tool call assembles with empty name/id → ToolNotFoundError: unknown tool "" (UNKNOWN_TOOL). The captured stream shows id/name present only on the first tool_calls delta, then id:"" / function.name:null on the subsequent argument deltas.

Root cause confirmed at current master (not yet fixed as of the latest push)

• packages/llm/llm-deepseek/src/translate.ts:159-160 still uses !== undefined, so a later id:"" / name:null delta overwrites the values captured from the first delta.
• packages/llm/llm/src/assembler.ts:71 still does partial.toolCallId = chunk.id unconditionally (unlike the guarded name line right below it).

Why only flash
deepseek-v4-flash follows the standard OpenAI SSE convention (id/name on the first delta only), while deepseek-v4-pro repeats them on every delta, which masks the bug.

There's already a patch with unit tests in a fork — see #3384 (kolawong, branch fix/llm-deepseek-null-tool-delta). Would be great to see it land in master.