[BUG] DeepSeek thinking-mode reasoning_content not passed back when tool-call assistant msg has empty reasoning -> HTTP 400

[SJT503]

Bug 2: DeepSeek thinking-mode reasoning_content not passed back when a tool-call assistant message has empty reasoning → HTTP 400 INVALID_REQUEST

Environment

• dsh CLI: 0.1.0-rc.6
• Model: deepseek-v4-pro with reasoningEffort: max (also observed at high)
• Provider route: deepseek-official (@deepseek-ai/dsh-llm-deepseek)

Steps to reproduce

1. Configure default model deepseek-v4-pro with reasoningEffort: max in settings.
2. Open a session in the web UI, run a task that makes the agent call a tool (e.g. load a skill).
3. In a later turn (after the tool-call turn), send any message.
4. The request fails immediately with:

An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (insufficient tool messages following tool_calls message)
code: INVALID_REQUEST, status: 400

(The DeepSeek API rejects the request while validating the conversation history.)

Root cause

DeepSeek's thinking mode requires that any assistant message carrying tool_calls must also pass back its reasoning_content. The adapter serializeAssistant in dsh-llm-deepseek/lib/index.js only includes reasoning_content when both tool calls AND reasoning are present:

return {
    role: "assistant",
    content: text,
    ...toolCalls.length > 0 && reasoning.length > 0 ? { reasoning_content: reasoning } : {},
    ...toolCalls.length > 0 ? { tool_calls: toolCalls } : {}
};

When a historical assistant message has tool calls but its reasoning block is empty/missing (e.g. persisted under high/max reasoning effort where reasoning blocks may not be stored), the adapter emits tool_calls without reasoning_content → DeepSeek returns 400 INVALID_REQUEST.

Direct API probe confirms: sending history with an assistant tool_calls message that lacks reasoning_content yields "The reasoning_content in the thinking mode must be passed back to the API."

Workaround

• Lowering reasoningEffort from max to high and starting a fresh session avoids the immediate failure, but the underlying serialization gap remains.

Suggested fix

Always include reasoning_content (even if empty string) on assistant messages that carry tool_calls, per DeepSeek thinking-mode passback requirements:

...toolCalls.length > 0 ? { reasoning_content: reasoning, tool_calls: toolCalls } : {}

[Electricitysheep]

thinking-mode 工具轮次空 reasoning → 400——和 #739 完全同族（serializeAssistant 省略空 reasoning 字段）。

已确认是 bug（官方适配器同场景不触发），我们第 6 章坑位 #8 有完整根因 + 验证点：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/06-advanced.md

[weijiafu14]

Cross-route measurement that closes off the workaround space and (hopefully) raises the priority of the adapter fix you isolated:

We fed an assistant history message carrying both a thinking block and a tool call through the real pi-ai transform (convertMessages, 0.82.1 and 0.84.1, fault-injection harness — unmodified code), plus a live leg against the real api.deepseek.com. Results (reasoning-history-results.json, case toolCallWithThinking):

• neither pi-ai version emits a reasoning_content field on replay — thinking text is inlined into content, tool_calls preserved, tool-role message present;
• that history is accepted fine by a non-thinking endpoint (live 200, follow-up turn completes).

Implication for this bug: a thinking-mode backend that requires the reasoning_content field back cannot be satisfied by either existing route — llm-deepseek drops it (your Bug 2), and the pi-ai route never constructs the field by design. So "switch the route" is not an escape hatch; the only real fix is the one you pointed at — llm-deepseek echoing reasoning_content back (including the empty-reasoning-on-tool-call edge you found).

Scope note: our live leg runs a non-thinking model (thinking mode 400s are exactly the unfixed part); the transform-side conclusion is version-stable.