Adapter: assistant() forwards empty text blocks → HTTP 400 from cloud endpoints (missing guard, still present in 0.2.1-alpha.1)

[ss-cong]

Summary

assistant() in the DeepSeek adapter emits { type: "text", text: "" } for empty text blocks when replaying history. Cloud endpoints reject such a request with HTTP 400, so any session whose retained history contains an empty text block breaks as soon as it is routed to a cloud model — switching models mid-session is enough to hit it.

Where

@deepseek-ai/dsh-llm-deepseek → lib/index.js, function assistant() (around L1539); the text case is the first branch of its message.content.map(...):

case "text": return { type: "text", text: block.text };   // no empty check

Why this looks like an oversight, not a decision

Two other content-to-block converters in the same file already guard the identical case:

line	code
~L1582	if (block.type === "text") return block.text ? [{ type: "text", text: block.text }] : [];
~L1622	case "text": return block.text.length === 0 ? [] : [{ type: "text", text: block.text }];

assistant() is the only one of the three without the guard, which matches "blank text block reaches the wire".

Observed impact

• Cloud route: request rejected with 400 (invalid_request_error class) — the turn cannot be retried into success while the shape stays inside the retained window.
• Self-hosted routes happen to tolerate it, so the defect is invisible until a session is switched to a cloud model.
• Workaround users have: start a new session (clears the window) — i.e. the failure costs the whole session.

Minimal repro

1. Produce a conversation where an assistant message ends up with an empty text block in the retained history (e.g. a turn that only produced reasoning/tool-call parts, or any interleaving that leaves an empty text part).
2. Route the same session to a cloud model and send one message.
3. Result: 400 from the cloud endpoint, repeatable as long as that block is inside the window.

Suggested fix (one line)

-case "text": return { type: "text", text: block.text };
+case "text": return block.text.length === 0 ? [] : { type: "text", text: block.text };

(also worth dropping whitespace-only blocks, e.g. block.text.trim().length === 0)

Version matrix checked

version	assistant() guard
0.2.0-rc.2	absent
0.2.1-alpha.1	absent (identical lib/index.js, 101,115 bytes)

So this is not fixed by upgrading within the published line. Happy to test a build with the guard if you want a confirming report.

[PerryLink]

这条的形态很明确："重放历史"缺少一次归一化——请把源码符号补上

1. 你描述的是一条边界归一化缺失

你的机制是：适配器的 assistant() 在重放历史时为空文本块发出 { type: "text", text: "" }，而云端端点会因此返回 400 ⇒ 只要会话保留的历史里有空文本块，一旦路由到云端模型就坏；切换模型就足以触发。

⇒ 这个形态（自建/本地路由容忍、云端不容忍；切换模型即触发）非常典型：问题不在模型，而在"我们发出去的请求里带了不该带的空块"。修法也是最便宜的一类——在构造请求时把空文本块丢掉（或合并），并在请求边界做一次归一化，而不是让每个 provider 各自容忍。

建议把诉求写成：

历史重放应当在构造请求时归一化：丢弃（或合并）空文本块；不应依赖各端点对空块的容忍度差异。

2. ⚠️ 一处我核不到，请你补（这条能不能修就靠它）

我按你给的位置在源码里找 llm-deepseek 的 assistant()，没有命中（translate.ts 里没有 assistant 这个名字，text: '' 在 packages/llm/llm-deepseek/src 下也没有命中）。

⇒ 请补源码侧的符号名与文件（不是 lib/index.js 的行号）。原因很实际：

• 你引的是构建产物行号，版本一动就失效（0.1.7-rc.2 → 0.2.1-alpha.1 有 714 个提交，packages/llm 占 70 个）；
• 我按名字搜不到 ⇒ 维护者也会先卡在这一步。

给出"文件 + 函数名 + 那一行"三件套，这条就能直接被人接手。

3. 你已写对的两点请保留

• "仍存在于 0.2.1-alpha.1" —— 我核到的是 HEAD 就是 0.2.1-alpha.1（5badb15009），所以你的基线已经是最新，无需再升级；这句让报告的价值立刻不同；
• "自建路由容忍、云端不容忍，所以切模型才暴露" —— 这是影响面的关键，它解释了为什么很多人遇不到。

4. 请再补一样

那 400 的响应体原文（云端返回的错误信息）。它能把这条从"我认为是空块"变成"端点明确拒绝了空块"，也能排除是别的字段（例如 content: [] 与 content: [{text:""}] 常被端点区分对待——请确认你观测到的是哪一种）。

一条边界

我确认的是按你给的名字在 llm-deepseek/src 下检索不到 assistant() 与空 text 块（因此需要源码符号）。"空块导致 400"这一因果以你的复现为准——我没有云端端点可测。

[ss-cong]

Answers to both asks — plus one correction that changes the proposed fix.

1. Source symbols

packages/llm/llm-deepseek/src/serialize.ts (not translate.ts), at 5badb15009:

• function assistant(message: Message, model: string, onReplayDegrade?: (reason: string) => void): WireBlock[] — declared at L26
• the unguarded branch — L30:

  case 'text': return { type: 'text', text: block.text }

• the two counterparts in the same file: L65 (user / tool-result path) and L93 (developer path)
• call site for history replay: L119 (? assistant(message, options.model, onReplayDegrade))

Permalink: https://github.com/deepseek-ai/deepseek-harness/blob/5badb15009/packages/llm/llm-deepseek/src/serialize.ts#L30

2. Raw 400 body, verbatim (two independent samples)

code=INVALID_REQUEST  status=400
messages.5.2: `tool_use` ids were found without `tool_result` blocks immediately after: call_61d5e034a62a40edb7024722. Each `tool_use` block must have a corresponding `tool_result` block in the next message. (request_id: 1e6d132b-f186-4627-8904-33476b12871d)

code=INVALID_REQUEST  status=400
messages.3.2: `tool_use` ids were found without `tool_result` blocks immediately after: call_e2c9e04e093a483e9a6859e2. Each `tool_use` block must have a corresponding `tool_result` block in the next message. (request_id: dbb9d7d2-4597-4741-954b-6d8809fb8593)

To be precise about what this proves: the body does not name the blank block — it reports the consequence (a tool_use with no immediately-following tool_result). The link to the blank text block is our inference, and §4 below is the before/after that backs it.

Answering your content: [] vs content: [{text: ""}] question directly: what we observe is a whitespace-only text block, i.e. { type: 'text', text: '\n' } — length 1, not 0 — not an omitted or empty content array.

3. Correction: the block is "\n", not "" — length === 0 does not cover it

• observed shape: { type: 'text', text: '\n' }; all 20 occurrences inside the retained window (29 across the session) were whitespace-only
• in every occurrence it sat between two tool-call blocks: [reasoning, tool-call(A), text("\n"), tool-call(B)]
• therefore all three branches in serialize.ts let it through: L30 has no check; L65 uses block.text ? … (truthy — "\n" passes); L93 uses block.text.length === 0 ("\n" passes as well)
• suggested condition: block.text.trim().length === 0 — or, more structurally, drop text blocks that have a tool_use on both sides

4. Before / after on one real session

• before: turn 1809 → 400 naming call_e2c9e04e093a483e9a6859e2; that id lives in assistant/message seq 64258, whose content was [reasoning, tool-call, text("\n"), tool-call]
• action: removed only those 20 whitespace-only text blocks sitting between tool-call pairs; nothing else changed (event count 64,699 → 64,699, seq untouched)
• after: the next turn on the same session and the same model (deepseek-official/deepseek-flash) completed — turn/end kind = completed, no error
• why it stayed hidden: those blocks were produced while the session ran on a local vLLM route (qwen38-nvfp4-upstream), which does not validate this; the session only broke when it was routed to a cloud model

Happy to test a build that carries the guard.

[ss-cong]

Two additions, mainly because the published package does not ship src/ at all:

• Package identity: @deepseek-ai/dsh-llm-deepseek@0.2.0-rc.2, main: lib/index.js, and its files field is ["lib/index.js", "lib/types/**/*.d.ts"]. So packages/llm/llm-deepseek/src has nothing to search — that is why assistant() and the empty-text case don't turn up there. The code lives in the built artifact only.
• The three-part anchor in that artifact:
  • file: node_modules/@deepseek-ai/dsh-llm-deepseek/lib/index.js
  • function: assistant(message, model, onReplayDegrade) — declared at L1539
  • line: the unguarded branch is L1543–1544 (type: "text" with block.text forwarded as-is); the two converters that do guard the same case are L1621 (case "text": return block.text.length === 0 ? [] : [{ type: "text", text: block.text }]) and L1582; the call site is L1666 (message.role === "assistant" ? assistant(message, options.model, onReplayDegrade) : …).

Caveat worth stating: those are build-artifact coordinates and will drift between releases (the version above is pinned for that reason). For a source-level anchor, the symbols/snippets are the durable part.

Thanks for the review — pinning down content: [] vs content: [{ type: "text", text: "" }] was the right thing to nail, and the "local routes tolerate it, cloud rejects it, switching models exposes it" framing came from your comment.

---

[PerryLink]

你补的源码位置我核到了——而且修法就写在同一文件里（我第一次找错了文件，向你说明）

1. 先认错：我第一次检索错了文件

我是在 packages/llm/llm-deepseek/src/translate.ts 里找 assistant() 的，当然找不到——它在 serialize.ts。你给的位置准确，我在 5badb15009 上逐条核对全部命中：

packages/llm/llm-deepseek/src/serialize.ts
:26  function assistant(message: Message, model: string, onReplayDegrade?: (reason: string) => void): WireBlock[] {
:30        case 'text': return { type: 'text', text: block.text }        ← 无守卫（你指的那处）
:119       ? assistant(message, options.model, onReplayDegrade)          ← 历史重放的调用点

2. ⭐ 而且同一文件里已经有一个正确的写法

我在同一文件里核到 :93：

case 'text': return block.text.length === 0 ? [] : [{ type: 'text', text: block.text }]

⇒ developer 路径已经过滤了空文本块，assistant 路径没有。 这就是确切的不对称，也让修法变成一句话：

让 :30 采用 :93 已有的守卫（空文本块不产出 wire block），并确认 onReplayDegrade 是否需要同时被通知。

建议你把这一点写进报告的诉求里——"同一文件已有正确写法，只差应用到重放路径"是维护者最容易接受的形式；比"请过滤空文本块"更强，因为它证明了团队自己认可的语义（developer 路径的行为就是规范）。

3. 关于你第二条补充（包内不含 src/）

你指出 files: ["lib/index.js", "lib/types/**/*.d.ts"] ⇒ 发布包不含 src/，所以只能在产物里检索。⇒ 这解释了我为什么在你给的产物行号上对不上源码行号。建议报告里同时给两组锚点（你后来的做法），因为：

• 源码锚点（serialize.ts:26/:30/:93/:119）⇒ 维护者直接改这里；
• 产物锚点（lib/index.js 的函数名 + 行）⇒ 让只看 npm 包的人也能复核。

你两条都给了，这正是最完整的形态。

4. 请补一样（决定严重度）

空文本块是从哪里来的——是模型真的产出过空 text，还是某些内容被其它环节清空后留下的壳？⇒ 这决定要不要同时在上游阻止空块生成，而不只是在这一处过滤。

5. 版本

0.2.1-alpha.1 与 0.2.0-rc.2 在这一点上我都核到同样缺少守卫（:30 仍是裸的 text: block.text）⇒ 当前存活项，无需等新版。

一条边界

我确认的是函数位置、:30 的无守卫写法、:93 的对照写法、以及 :119 的调用点（逐行核对）。"空文本块导致云端 400"这一因果以你的 400 原文为准——我没有云端端点可测。

[ss-cong]

Answer to your §4 (where the blank blocks come from) — plus a live before/after, because the same thing happened again in the same session while we were talking.

1. Origin: they come in on the provider stream, and only on our local route

• Every occurrence is exactly { type: 'text', text: '\n' } — length 1, never '', never content: [] (so it is not a cleared/empty shell, and not an omitted array).
• All of them — 29 across the session, 5 of them from today — sit exactly between two adjacent tool-call blocks; the content shape is always reasoning, tool-call, text("\n"), tool-call.
• They only ever appear in turns produced by our self-hosted vLLM route (spark-nvfp4 / qwen38-nvfp4-upstream). Turns from deepseek-official / deepseek-flash in the same session contain none, before or after.

We cannot see the raw SSE any more, but DSH has nothing to invent a \n from: the whitespace arrives on the provider stream and is recorded verbatim as an assistant text block. So a "do not produce it" fix would have to live in that server; what DSH controls — and what fixes our case — is normalizing at the request boundary.

2. Live before/after, one session, same cloud provider and model

• before: turn 1793 and turn 1809 → 400 INVALID_REQUEST, naming call_61d5e034a62a40edb7024722 and call_e2c9e04e093a483e9a6859e2
• after (local guard applied 2026-10-05 13:23): turn 1822 on deepseek-official/deepseek-flash → completed

Why this is a real test rather than luck:

• the session ran on the local route again and produced 5 new blank blocks (assistant/message seq 65367, 65387, 65401, 65408, 65440), all the same shape;
• those 5 blocks are still in the log, and no compaction ran after them (seq > 65440 contains no compaction events), so turn 1822's request carried them;
• the same shape returned 400 twice before the guard; now it completes — and so do the 5 turns after it (1823–1827).

3. One correction to your §2

The asymmetry you found is the right framing, but copying :93 verbatim would not fix our case: block.text.length === 0 lets "\n" (length 1) through. It needs block.text.trim().length === 0 — or, structurally, dropping text blocks that have a tool_use on both sides. Our local guard uses the trim() form and additionally keeps the block when it is the message's only block, so we never emit content: [] (the other shape the endpoint rejects). We will drop the guard as soon as a release carries the fix.

[PerryLink]

⚠️ 你这条更正了我的修法——"\n" 不是空字符串，我上一轮给的守卫抓不住它

1. 更正：我上一轮的建议对你这个形态无效

我上一轮说"让 :30 采用 :93 已有的守卫"。但按你现在给的实测：

• 每次出现都是 { type: 'text', text: '\n' }，长度 1；
• 从不是 ''，也不是 content: []。

⇒ 而 :93 的守卫是 block.text.length === 0 ? [] : [...] ⇒ '\n' 的 length 是 1，会原样通过。所以我那条修法在你的场景下不生效，请以这个更正为准。

2. 我核实的两点（HEAD = dsh-v0.2.1-alpha.1）

1. serialize.ts:30 仍然没有守卫（case 'text': return { type: 'text', text: block.text }）；
2. 在 packages/llm/llm-deepseek/src 全目录检索 trim() 相关守卫：零命中 ⇒ 这套代码里没有任何"仅空白也算空"的处理 ⇒ 这与你的观察完全一致（"\n" 一路透传）。

3. ⇒ 修正后的诉求（把 length === 0 改成"空白也算空"）

重放历史时应当丢弃仅含空白的文本块（text.trim().length === 0 ⇒ 不产出 wire block），而不仅是 length === 0 的那些。

并且建议同时改 :65（user/tool-result 路径）与 :93（developer 路径）——它们现在是 length === 0，存在同一个缺口：只堵 assistant 这条路，同一个 provider 从别的角色发来的 "\n" 仍会漏过去。

4. 你第 3 点（只有本地 vLLM 路由出现）是很强的证据，建议放大

你写：29 次全部出现在自建 vLLM 路由（spark-nvfp4 / qwen38-nvfp4-upstream），而同一会话里 deepseek-official / deepseek-flash 的轮次一次都没有。

⇒ 这说明这些块是 provider 发出来的（reasoning, tool-call, text("\n"), tool-call 这个固定夹层形状也支持"上游模型在两次工具调用之间吐了个换行"），不是 DSH 自己造出来的。建议把"同会话双路由对照"写成证据——它同时排除了"DSH 生成"和"某个中间层伪造"两种解释。

⇒ 于是这条就有两个正当诉求：① DSH 侧不要转发仅空白块；② 该行为对云端端点致命（400），所以 DSH 侧的过滤是必要的防线，即使上游也改。

5. 请补一样

那 400 的响应体原文（你上一轮给过一部分）⇒ 它能确认云端到底是被空白块还是被别的字段拒的。你已写了"DSH 没有地方能凭空造出 \n"——这个论证我认同，但把 400 原文贴全，这条就没有可被质疑的环节了。

[ss-cong]

Closing the loop with a ready-to-apply source change, so nobody has to re-derive it.

1. The three sites, all with the same gap

packages/llm/llm-deepseek/src/serialize.ts @ HEAD:

• :30 (assistant / replay path) — no guard at all:
  case 'text': return { type: 'text', text: block.text }
• :65 (user / tool-result path) — truthiness only, so "\n" passes:
  if (block.type === 'text') return block.text ? [{ type: 'text', text: block.text }] : []
• :93 (developer path) — length only, so "\n" passes:
  case 'text': return block.text.length === 0 ? [] : [{ type: 'text', text: block.text }]

2. Suggested diff

-  return message.content.map((block, index): WireBlock => {
+  return message.content.flatMap((block, index): WireBlock | [] => {
     switch (block.type) {
-      case 'text': return { type: 'text', text: block.text }
+      case 'text': {
+        const text = block.text ?? ''
+        // whitespace-only text between tool calls makes the Messages API split the
+        // message, so the earlier tool_use loses its immediately-following tool_result
+        if (text.trim().length === 0 && message.content.some(b => b.type === 'tool-call')) return []
+        return { type: 'text', text: block.text }
+      }

plus :65 and :93 → block.text.trim().length === 0 ? [] : [...].

Two notes from running this guard in production:

• do not drop a whitespace-only block when it is the message's only block — that emits
  content: [], which the endpoint also rejects. Keep it in that case.
• trim() rather than length === 0, for the reason in the previous comment.

3. The dual-route contrast, as numbers

• 29 whitespace-only blocks across the session; 29/29 are exactly { type: 'text', text: '\n' },
  and 29/29 sit exactly between two tool-call blocks (reasoning, tool-call, text("\n"), tool-call).
• They appear only in turns produced by our self-hosted vLLM route
  (spark-nvfp4 / qwen38-nvfp4-upstream). Turns from deepseek-official / deepseek-flash in the
  same session contain zero — before and after.
• Later today the session switched routes twice more: 5 new blocks appeared
  (assistant/message seq 65367, 65387, 65401, 65408, 65440) and the following cloud turns
  completed (turn 1822–1827) with those blocks still present, because the guard drops them at
  serialization. Same session, same model, same window: 400 before the guard, completed after.

4. On the 400 body

What was pasted is the complete record DSH retains: message, code = INVALID_REQUEST,
status = 400, request_id. There is no larger JSON envelope in our logs, and the body does not
mention the blank block — it reports the consequence. The causal link rests on the before/after
above, not on the body text. We can't fetch the endpoint's raw envelope ourselves without
extracting our account credentials, which we won't do.