An empty id/name in a later tool-call delta overwrites a good one: every call becomes unknown tool ""

[HuChundong]

On 0.1.0-rc.7, every tool call from deepseek-v4-flash started failing with Error: unknown tool "". The arguments arrive intact; only the call's id and name are empty by the time the tool layer sees them. Switching the same session to deepseek-v4-pro fixes it immediately, so this is specific to how one model's stream is shaped — but the part worth fixing looks like it is on the harness side, because the same accumulator already guards one field and not the other.

Two things make it costly beyond the failed call: the agent cannot recover, and it blames itself. Its own reasoning reads

I've made the same mistake three times: I used an empty string for the tool name. I need to invoke the tool properly with name="bash".

and the next call is empty again, because the name it emitted was never the problem. repeat-tool-reminder then fires, which reads to a user as the agent being stuck in a loop.

What the frames look like

From the session log, one bash call (turn 1, step 4). These are the harness's own chunk vocabulary — post-translation, not raw provider SSE; see the caveat at the end.

{"type":"block-start","index":2,"blockType":"tool-call"}
{"type":"tool-call-delta","index":2,"id":"call_fe70060caf4d47938d2ae88d","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 && ls -la\""}
{"type":"tool-call-delta","index":2,"id":"","name":null,"argumentsDelta":", \"description\": \"Show working"}
{"type":"tool-call-delta","index":2,"id":"","name":null,"argumentsDelta":" directory and list files\"}"}
{"type":"block-end","index":2,"block":{"type":"tool-call","id":"","name":"",
  "arguments":"{\"command\": \"pwd && ls -la\", \"description\": \"Show working directory and list files\"}"}}

and the result:

{"type":"tool/call","data":{"turn":1,"step":4,"callId":"","name":"",
  "arguments":"{\"command\": \"pwd && ls -la\", ...}"}}
{"type":"tool/result","data":{"error":{"name":"ToolNotFoundError","code":"UNKNOWN_TOOL"},
  "...":"Error: unknown tool \"\""}}

The first delta carries id and name correctly. The arguments accumulate perfectly across every later delta. Only the identity is lost.

Where it looks reachable

Per the OpenAI-compatible streaming contract, id and function.name appear on the first delta for an index and later deltas carry argument fragments only — so correlating by index and caching the identity, which is what packages/llm/llm-pi-ai/src/stream.ts does, is right. What is not covered is a provider that sends an empty string rather than omitting the field.

Two places treat that case differently, and the inconsistency is the tell:

packages/llm/llm-pi-ai/src/stream.ts — the name is guarded on length, the id is not:

yield {
  type: 'tool-call-delta',
  index: event.contentIndex,
  id: CallId(known?.id ?? ''),
  ...known?.name !== undefined && known.name.length > 0 ? { name: known.name } : {},
  argumentsDelta: event.delta,
}

packages/llm/llm/src/assembler.ts:70-71 — the same asymmetry, the other way round from what a reader expects:

partial.toolCallId = chunk.id            // unguarded: "" overwrites a good id
if (chunk.name) partial.toolCallName = chunk.name   // guarded

The assembler's id line is masked in practice because block-end replaces the accumulated block wholesale (partial.block = chunk.block), but it is the same latent defect on a second path.

A one-line rule would cover both: an empty value never replaces a known one.

What I have not proven

I did not capture the raw SSE from the provider, so I cannot say whether deepseek-v4-flash sends id: "" and function.name: "" or omits them. The id: "" visible above is the harness's own re-emission (CallId(known?.id ?? '') always produces a string), which hides the provider's shape. If the provider omits them, the guards as written already handle it and the emptiness originates inside pi-ai's event.toolCall at toolcall_end — worth checking either way, since toolcall_end is where the final block's id/name come from.

Either way the harness ends up trusting a value it received as empty, and the failure mode is one an agent cannot work around.

Timeline, in case it helps date the provider-side change

All on one deployment, same image, same session lineage:

time	event
10:17	rolled onto rc.7
10:33:59	last successful tool call (bash)
10:34:16	first unknown tool ""
11:35:47	still failing, every call

Tools that had been working that morning: bash, read, read_image, skill, web_search. Nothing in llm-pi-ai/src/stream.ts changed between rc.6 and rc.7, so the trigger is very likely provider-side; the harness's exposure to it is what this report is about.

Environment

dsh 0.1.0-rc.7, provider deepseek-official, model deepseek-v4-flash (broken) vs deepseek-v4-pro (fine). Linux container, agent preset standard.

CONTRIBUTING says external pull requests are not being accepted at the moment, so this is a report rather than a patch. Happy to supply the full session log frames if useful.

[HuChundong]

Correction: I pointed at the wrong adapter above, and two new facts narrow it further.

1. The active code path is llm-deepseek, not llm-pi-ai. I checked the deployment's settings.yaml: it has no llm-pi-ai: section, so that adapter is mounted dormant exactly as the base composition documents, and deepseek-official is served by the native adapter. Please read the report above against packages/llm/llm-deepseek/src/translate.ts rather than packages/llm/llm-pi-ai/src/stream.ts. Sorry for the detour.

That adapter guards both fields the same way:

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

!== undefined admits "". So a later delta carrying id: "" / function.name: "" overwrites the good values from the first delta — which is precisely the transition in the recorded frames (call_fe70060caf4d47938d2ae88d → ""). The one-line rule from the report still applies, just here:

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

2. deepseek-v4-flash works in other tools. The reporter uses the same model through a different client with no such failure. That is the strongest evidence that whatever the provider sends is within what other OpenAI-compatible clients already tolerate — so this is a robustness gap on the harness side rather than a broken provider response, and deepseek-v4-pro working is just a difference in how its stream happens to be chunked, not a fix.

The asymmetry noted in the report still stands as a separate latent case: llm/src/assembler.ts:70-71 guards name (if (chunk.name)) and does not guard id, and llm-pi-ai/src/stream.ts guards name on length > 0 and does not guard id. Three places, three different standards for the same question.