[bug]llm-deepseek: SSE tool_calls id/name overwritten by empty-string deltas

[godkillerwy]

Version

@deepseek-ai/dsh@0.1.0-rc.6 (bundled dsh-llm-deepseek).

Environment

An OpenAI-compatible chat-completions gateway whose streaming SSE emits
tool_calls[].id and tool_calls[].function.name as empty strings ""
in every chunk after the first one, instead of omitting them.

This deviates from OpenAI's official spec (which only sends id/name in
the opening chunk and elides them afterwards), but such gateways exist in
the wild and dsh currently mis-handles them, making tool calls unusable
end-to-end.

Repro (illustrative SSE chunks)

chunk 1: tool_calls[0] = {id:"call_xxx", function:{name:"ls",  arguments:""}}
chunk 2: tool_calls[0] = {id:"",         function:{name:"",    arguments:"{"}}
chunk 3: tool_calls[0] = {id:"",         function:{name:"",    arguments:"\"path\":\"/tmp\"}"}}

Expected

Final assembled tool-call block: id="call_xxx", name="ls".

Actual

Block collapses to id="" and name="". Downstream:

1. Agent loop emits a tool/call with empty name.
2. Local tool registry answers ToolNotFoundError: unknown tool "".
3. Next model request contains assistant.tool_calls[].function.name = "",
   which strict validators reject with HTTP 400:
   invalid input messages format. 'name'.

Net user-visible effect: tools never work on this gateway; each turn
either fails to invoke a tool or 400s on the follow-up request.

Root cause

packages/llm/deepseek/.../adapter.ts (published as
dsh-llm-deepseek/lib/index.js around lines 321–322):

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

"" satisfies !== undefined, so each subsequent delta chunk overwrites
the good values captured from chunk 1.

Suggested fix

Treat empty strings as absent, matching the intent of "only present on the
first chunk":

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

Verified locally: after this one-liner, tool calls work as expected on the
same gateway/model/session. Happy to open a PR if maintainers prefer.

Additional context

• OpenAI's own SSE emits id/name only on the opening chunk, so this fix
  also stays correct for compliant providers.
• The arguments accumulator already tolerates empty string via
  ?? "" + +=, so no change is needed there.

[DRAG0NM]

已定位根因：dsh-llm-deepseek 的 SSE 流装配器在合并 tool_calls[] delta 时，用 call.id !== void 0 / call.function?.name !== void 0 作为写入守卫（lib/index.js L321-322）。对"后续块用空字符串 "" 占位 id/name"的 OpenA… 完整源码定位与修复方案见 #885 。

[chjinche]

Here’s a workaround that worked for me: use the same endpoint through a Custom Provider instead of deepseek-official.

"<custom-provider-section>":
  providers:
    "<provider-id>":
      displayName: Custom DeepSeek
      apiKeyEnv: DEEPSEEK_API_KEY
      api: openai-completions # or openai-responses / anthropic-messages
      baseURL: https://your-endpoint.example/v1
      compat: # only needed for OpenAI Chat Completions
        thinkingFormat: deepseek
      models:
        - id: deepseek-v4-flash
          name: DeepSeek V4 Flash
          contextWindow: 262144
          maxTokens: 32768

The existing API key can be reused, and I didn’t need to change DSH or the gateway.

One small gotcha: create a new session after switching providers. Existing sessions keep the provider they started with.