[Bug] llm-deepseek: assistant() replays a text block placed after tool_use, and strict Messages endpoints then reject the session forever

[meteorfall]

Affected: @deepseek-ai/dsh-llm-deepseek 0.2.1-rc.3 — packages/llm/llm-deepseek/src/serialize.ts, assistant() (~L52-82), used by dsh-tui 0.17.0

Severity: Medium — rare, but permanently poisons a session

Reproducibility: observed in 3 assistant messages out of 2790 tool-calling messages over 3 days; the resulting HTTP 400 is 100% repeatable once such a message is in history

Summary

assistant() preserves the model's own block order when replaying history. When an upstream reply puts its text block after its tool_use blocks — which OpenAI-compatible relays do produce — that order is written to the session and replayed verbatim. The strict Anthropic Messages endpoint then rejects every subsequent request in that session with 400, permanently.

Evidence

Three assistant messages in my sessions carry this shape:

{"type":"assistant/message","data":{"turn":1,"step":43,"message":{"role":"assistant","content":[
  {"type":"reasoning","text":"..."},
  {"type":"tool-call","id":"call_6831db58f35f4fe791143f7d","name":"pwsh","arguments":"..."},
  {"type":"tool-call","id":"call_7e7e67338e28426f98480a9d","name":"pwsh","arguments":"..."},
  {"type":"text","text":"⏵ 跑既有测试并核对脚本改动"}
]}}}

Every tool/call has a matching tool/result in the same step, and the serializer's pending invariant passes — the ids are paired. What fails is the ordering requirement on the assistant side: the endpoint wants the assistant's tool_use blocks to be the last blocks of that message.

Both errors are the same root cause:

messages.85.3: `tool_use` ids were found without `tool_result` blocks immediately after: call_6831db58..., call_7e7e6733... (request_id: ...)
The `content[].thinking` in the thinking mode must be passed back to the API. (request_id: ...)

The second one is the same message when its reasoning block is absent: with a text block trailing the tool calls, the endpoint reports the missing thinking rather than the trailing text.

Isolation (what I verified)

I ran the same history against three endpoints, all with real keys:

endpoint	history tool_use, text	history text, tool_use
api.deepseek.com/anthropic/v1/messages (native)	400	200
api.deepseek.com/v1/chat/completions (OpenAI)	200	200
via newAPI, channel type 43 (native passthrough)	400	200
via newAPI, channel type 1 (converted to OpenAI)	200	200

So: the data is only rejected by the strict Messages endpoint, and only because of block order. It is not a pairing bug, not an empty-content bug, and not specific to any gateway.

I also sampled streaming replies from the relay that produces these messages. The order is not stable: in one 10-run sample, 4 replies came back thinking, tool_use, tool_use, text (poisonous) and 6 came back thinking, text, tool_use, tool_use (fine); a later 20-run sample produced 0/20 poisonous. The upstream SSE delta order is always reasoning_content → content → tool_calls, so this is the model placing its commentary inconsistently, not a conversion artifact.

Proposed fix

In assistant(), emit blocks in a stable order rather than the recorded one: thinking blocks first, then text, then tool_use blocks last. text before tool_use is accepted by the endpoint (table above), so this is safe for both routes and needs no change to the durable session format.

// sketch
const blocks = message.content
const rank = (b) => (b.type === 'reasoning' ? 0 : b.type === 'text' ? 1 : 2)
const ordered = [...blocks].sort((a, b) => rank(a) - rank(b)) // stable sort

readReplay's signature array is index-aligned to message.content, so the reordering has to carry the replay metadata along (zip block+replay, sort, unzip) — otherwise signatures land on the wrong block.

An alternative, if preserving exact model output is preferred: keep the order but refuse to replay a poisoned history, degrading with a clear INVALID_REPLAY_STATE diagnostic the way cross-model history already degrades. That avoids the permanent 400 without changing what gets sent.

Why this is worth fixing in the adapter

The failure mode is asymmetric: the session looks fine locally, the local invariant passes, and the damage only appears when the same session is routed to a stricter endpoint (a fallback channel, a provider switch, or a gateway whose primary channel is an OpenAI relay). By then the offending message is far in the past and every new turn fails.

Related

• [Bug][Windows 0.2.1-rc.2] 切换到 deepseek-official 后报 tool_result 缺失，但本地结果及序列化配对均存在 #10186 — same 400 text, different cause (empty tool_result content); the id-pairing check passing locally is common to both
• [bug] llm-deepseek: user text serializes before role:tool messages, breaking the tool_calls adjacency requirement #3046 — ordering bug on the user side (role:"tool" after text); this report is the assistant-side counterpart
• Adapter: assistant() forwards empty text blocks → HTTP 400 from cloud endpoints (missing guard, still present in 0.2.1-alpha.1) #8836 — empty text blocks forwarded; also an assistant() output-shape issue
• [Bug] 历史里的空 reasoning 块会序列化成空 thinking 块，导致已有会话切到严格的 Anthropic Messages 网关后永久失败 #9239 — empty reasoning blocks serialized as empty thinking, permanently failing after a route change; same "history shape + stricter endpoint" pattern

No API keys, project contents, paths or full session logs are included. Happy to produce a patch with a regression test in serialize.spec.ts if the maintainers want the ordering fix in this form.