Bug: streamed tool-call deltas with empty id/name overwrite valid values

[starrain1031]

Summary

When @deepseek-ai/dsh-llm-deepseek consumes streamed tool calls from a DashScope OpenAI-compatible endpoint, later argument-only deltas may contain empty-string id and function.name fields.

The translator treats these empty strings as authoritative updates and overwrites the valid ID and name received in the first delta.

As a result, the completed tool call has id: "" and name: "", and tool dispatch fails with:

ToolNotFoundError: unknown tool ""

Environment

• @deepseek-ai/dsh: 0.1.0-rc.6
• Provider route recorded by the session: deepseek-official
• Endpoint: DashScope OpenAI-compatible /chat/completions
• Model: deepseek-v4-flash
• Streaming enabled
• Reproduced with the web_search tool

Observed stream

The first tool-call delta is correct:

{
  "type": "tool-call-delta",
  "index": 2,
  "id": "call_example",
  "name": "web_search",
  "argumentsDelta": ""
}

Later argument-only deltas contain empty metadata:

{
  "type": "tool-call-delta",
  "index": 2,
  "id": "",
  "name": "",
  "argumentsDelta": "{"
}

Additional argument fragments continue with the same empty metadata:

{
  "type": "tool-call-delta",
  "index": 2,
  "id": "",
  "name": "",
  "argumentsDelta": "\"query\": \"example\"}"
}

The final block is then emitted as:

{
  "type": "block-end",
  "index": 2,
  "block": {
    "type": "tool-call",
    "id": "",
    "name": "",
    "arguments": "{\"query\": \"example\"}"
  }
}

Harness subsequently attempts to dispatch a tool whose name is an empty string:

ToolNotFoundError: unknown tool ""

The failure occurs before the actual web_search implementation is executed.

Root cause

The current translator overwrites stored metadata whenever the incoming field is not undefined:

https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/llm/llm-deepseek/src/translate.ts

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

For an empty string, both conditions are true. Therefore, a later argument-only delta erases the valid ID and name received earlier.

DashScope streaming behavior

DashScope’s official Function Calling documentation shows that later streamed argument chunks may contain an empty tool-call ID and no new function name.

Consumers are expected to merge tool-call deltas by index, retain the metadata from the first non-empty delta, and append only the argument fragments:

https://www.alibabacloud.com/help/en/model-studio/qwen-function-calling

Semantically, the empty metadata in a later delta means “no update in this chunk,” not “clear the previously received value.”

Proposed fix

Only replace stored metadata when the incoming value is a non-empty string:

if (typeof call.id === 'string' && call.id.length > 0) {
  block.callId = call.id
}

const name = call.function?.name
if (typeof name === 'string' && name.length > 0) {
  block.name = name
}

The argument fragment should continue to be appended normally:

const fragment = call.function?.arguments ?? ''
block.text += fragment

Missing regression coverage

The current translator tests cover the standard shape where later deltas omit id and name:

https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/llm/llm-deepseek/tests/translate.spec.ts

However, they do not cover the DashScope-compatible shape where later deltas explicitly contain empty strings.

A regression test could use:

firstChunk,
{
  choices: [{
    delta: {
      tool_calls: [{
        index: 0,
        id: 'call_example',
        type: 'function',
        function: {
          name: 'web_search',
          arguments: '',
        },
      }],
    },
  }],
},
{
  choices: [{
    delta: {
      tool_calls: [{
        index: 0,
        id: '',
        type: 'function',
        function: {
          name: '',
          arguments: '{"query":',
        },
      }],
    },
  }],
},
{
  choices: [{
    delta: {
      tool_calls: [{
        index: 0,
        id: '',
        type: 'function',
        function: {
          name: '',
          arguments: '"example"}',
        },
      }],
    },
  }],
},

The final assertion should verify that the original ID and name are preserved:

expect(finalBlock).toEqual({
  type: 'tool-call',
  id: 'call_example',
  name: 'web_search',
  arguments: '{"query":"example"}',
})

Expected behavior

• Merge tool calls using the wire index.
• Preserve the first non-empty id and name.
• Ignore later empty metadata placeholders.
• Concatenate all function.arguments fragments.
• Dispatch the completed call as web_search, rather than an empty tool name.

[weijiafu14]

这个百炼故障现在可以直接绕开，不需要改 llm-deepseek 源码：

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add pi-provider-alibaba-bailian

export ALIBABA_API_KEY='<your Bailian key>'
dsh web

然后选择 Alibaba Bailian / deepseek-v4-flash。这条路由使用 pi-ai 的 OpenAI Chat SSE 解析；它保留首个非空 id/name，百炼续片里的 id:""、name:"" 或 null 不会覆盖已经组装好的工具身份。

我们已经完成两层验证：

• 按百炼抓包形态同时回放空字符串和 null 续片，真实 DSH loop 正确执行工具、配对 tool/result 并继续下一轮；
• 使用普通百炼 Key 对真实 DashScope 公网 deepseek-v4-flash 端点调用，工具名和 callId 保留，工具结果成功回传，最终回复正常完成。

请直接按上面步骤试；如果你的地域、模型或账号返回不同错误，把所选模型和错误贴出来，我们继续按真实场景修。

项目：https://github.com/weijiafu14/pi2dsh

[snowshadow]

Community mitigation (not an official fix): dsh-llm-gateway-compat sanitizes empty streamed tool-call id/name, and can write llm-pi-ai compat.supportsDeveloperRole: false then retry once. Write-up: #3814

社区缓解，不是官方修复。请自行 review 源码后再安装。