[BUG][Windows 0.2.1-rc.2] DeepSeek Messages 流式 tool 参数 JSON 损坏 → MALFORMED_RESPONSE 整轮中止且不重试

[ltmroberthk915]

环境

项	值
产品	DSH Desktop（DeepSeek Harness 桌面端）
版本	0.2.1-rc.2（nightly 渠道；app.asar 构建于 2026-10-17 17:20:50）
相关包	@deepseek-ai/dsh-llm-deepseek 0.2.1-rc.2、@deepseek-ai/dsh-llm 0.2.1-rc.2、dsh-llm-retry
系统	Windows 11 x64
模型/路由	deepseek-flash，DeepSeek Messages（anthropic 兼容端点 https://api.deepseek.com/anthropic）
场景	长时间自动化任务：连续 computer_* 桌面操作 + CDP 浏览器脚本 + 长中文工具参数

症状

会话多轮中出现整轮失败，界面报错：

本轮运行失败：DeepSeek Messages stream: tool input is invalid JSON
（错误代码 MALFORMED_RESPONSE）

• 频率：约 30 分钟内 ≥3 次（2026-10-19 约 02:40–03:15 CST）。
• 时机：均为工具调用密集、单次工具参数较长（大段中文/长 URL）的阶段；不是某个特定工具必现。
• 后果：整轮 abort，已执行的部分动作保留（半完成状态，需要人工善后）；无自动重试。

代码定位（app.asar，可直接检索）

1. 报错点 — adapter translate()，字节偏移 81261931：

} else { // message_stop
  if (reason === void 0 || [...blocks.values()].some((block) => !block.closed))
    return malformed("message_stop without settled blocks and stop reason");
  if (blocks.size === 0 && reason.kind === "stop")
    throw new LlmError("DeepSeek Messages returned no content", "EMPTY_RESPONSE");
  if (reason.kind !== "max-tokens") for (const { content } of blocks.values()) {
    if (content.type !== "tool-call") continue;
    let parsed;
    try {
      parsed = JSON.parse(content.arguments);
    } catch (_invalidProviderToolJson) {
      return malformed("tool input is invalid JSON");   // ← 本 bug
    }
    object(parsed);
  }

2. malformed() → 固定错误码 MALFORMED_RESPONSE（偏移 81255782）：

function malformed(detail) {
  throw new LlmError(`DeepSeek Messages stream: ${detail}`, "MALFORMED_RESPONSE");
}

3. 参数拼装（注意第 3 点的覆盖语义）：

// startBlock() @ 81256501：tool_use 初始 input 先整体序列化
case "tool_use":
  content = { type: "tool-call", id: ..., name: ...,
              arguments: JSON.stringify(object(native.input)) };

// deltaChunk() @ 81257504：partial_json 逐段累加
if (delta.type === "input_json_delta" && content.type === "tool-call") {
  block.json += string(delta.partial_json);
}

// content_block_stop：用 delta 拼串整体覆盖 start 时的 input
if (block.content.type === "tool-call" && block.json.length > 0)
  block.content.arguments = block.json;

4. 默认重试集合不含 MALFORMED_RESPONSE（偏移 81546383）：

const DEFAULT_RETRYABLE_CODES = Object.freeze([
  EMPTY_RESPONSE_CODE,
  'RATE_LIMIT',
  'SERVER',
  'TIMEOUT',
  'TRANSPORT'
]);

→ EMPTY_RESPONSE（更坏的情况）会重试，MALFORMED_RESPONSE 不重试；而参数解析失败时工具从未执行，重试本身是安全的。

可能根因（建议按顺序排查）

1. 提供方流式 input_json_delta 序列不完整/损坏（SSE 分帧、网关截断、网络抖动）：adapter 校验正确，但错误被归为不可重试，且错误信息不含工具名/片段，无法定位。
2. startBlock 的 native.input 与后续 delta 的合并语义冲突：若提供方在 content_block_start 给了非空 input、随后又发 input_json_delta，当前实现会用 block.json 整体覆盖初始 input（丢前缀），拼出的 JSON 天然不完整 → 直接触发本错误。
3. 长 CJK 内容下的 SSE 字符串解码边界问题（多字节字符跨帧截断）导致 partial_json 中混入替换字符，使 JSON 非法。

建议修复

1. 把「工具参数 JSON 解析失败」纳入可重试（1–2 次、指数退避），或提供 adapter 级 retryHints；理由：解析失败时工具未执行、无副作用。
2. 失败时降级而非中止整轮：丢弃该 tool_call、回一条"工具参数解析失败，请重试该工具调用"的 tool result 让 agent 自恢复；至少 UI 提供「继续本轮」入口。
3. 错误信息补全：tool name、block index、arguments 长度、首尾各 200 字符、provider request id。
4. 可选原始流留痕：诊断开关下把该次请求的 raw SSE 落盘，便于定位是网关还是本地解析。
5. 合并语义修正：content_block_start.input 非空时与 deltas 合并后再 parse，或对候选串分别尝试。

复现建议

长会话 + 高频工具调用，且工具参数包含大段中文（40–60 汉字、含全角标点）与长 URL；预计 30–60 分钟内出现 1–3 次。开启 raw SSE 留痕后可直接区分：缺 delta（流中断）/ deltas 拼串非法（内容问题）/ start input 被覆盖（合并语义问题）。

---

该错误与具体业务内容无关，属传输/适配层问题，建议按长任务稳定性 P1 处理。

[argszero]

Thanks for the detailed report — the reproduction steps and the version numbers made this checkable in the source.

Why nothing retried

The failure is raised by the Messages adapter, not by the transport:

// packages/llm/llm-deepseek/src/translate.ts
if (reason.kind !== 'max-tokens') {
  for (const { content } of blocks.values()) {
    if (content.type !== 'tool-call') continue
    let parsed: unknown
    try { parsed = JSON.parse(content.arguments) } catch (_invalidProviderToolJson) { return malformed('tool input is invalid JSON') }
    object(parsed)
  }
}

and the provider retry policy only covers five codes:

// packages/llm/llm/src/retry-policy.ts
const DEFAULT_RETRYABLE_CODES = Object.freeze([
  EMPTY_RESPONSE_CODE, 'RATE_LIMIT', 'SERVER', 'TIMEOUT', 'TRANSPORT',
])

MALFORMED_RESPONSE is not among them. So a response that carries nothing is retried up to five times, while a response that carries a request which merely failed to parse is abandoned on its first occurrence. That asymmetry is the bug, and it is worth fixing here regardless of what the plugin below does.

The one-line knob, and why it is awkward on your build

retryPolicy.retryableCodes accepts arbitrary codes, so:

retryPolicy:
  mode: normal
  retryableCodes: ['EMPTY_RESPONSE', 'RATE_LIMIT', 'SERVER', 'TIMEOUT', 'TRANSPORT', 'MALFORMED_RESPONSE']

works — but two things get in the way on a released desktop build. A profile's config entry replaces the provider config object as a whole rather than merging into it, so that block has to restate every field the deployment needs; and the desktop's own route configuration lives inside the packaged app.asar, where an overlay is the only way in. mode: 'always' also exists, but it makes every failure retryable — deterministic 400s, a bad key, a cancelled turn — which is a large hammer for one code.

A plugin that does just this

Since the knob is hard to reach from where you are, I wrote the recovery as a plugin you can mount without touching the packaged config:

https://github.com/argszero/dsh-malformed-tool-json-guard — @argszero/dsh-malformed-tool-json-guard

- insert:
    - id: malformed-tool-json-guard
      name: '@argszero/dsh-malformed-tool-json-guard'
      config:
        mode: guard      # or 'observe' to count without retrying

It listens to agent/assistant-stream and agent/request-error, both global events that every provider's attempts pass through, so it is adapter-agnostic and holds no reference to the llm service. It retries only when the same attempt both carried a tool-call block whose arguments are not a JSON object and ended with MALFORMED_RESPONSE — one half alone would fire on attempts that are not this shape. The retry is bounded to one per step by default and does not consume the provider's own retry budget.

The package name is not yet on npm (the publish token is still pending), so npm install will not find it; the repository is complete and installable from a checkout. I will follow up here when it is published.

Three causes it is not

While reading the adapter I checked the explanations that seem most likely, so you do not have to:

• A Chinese character split across SSE frames. Not it. parseSse runs a TextDecoderStream, which holds partial multi-byte sequences across frame boundaries, and the assembled string is what gets parsed — the character is whole again before JSON.parse sees it.
• content_block_start.input overwriting the accumulated arguments. Not it either. Under the Anthropic block contract the start event carries an empty object for a tool call and every argument byte arrives as input_json_delta; the accumulator starts from the deltas.
• A truncated stream. A stream that ends early raises STREAM_CLOSED from the last line of the same file, not MALFORMED_RESPONSE. Your code therefore proves that message_stop arrived and the block closed — the bad JSON was assembled upstream of the harness, on the gateway, in the SSE framing, or at the provider. Nothing on this side can tell which.

That is also why the plugin retries rather than repairs: the harness cannot see where the corruption happened, and inventing a repair would be guessing.

Being honest about what a retry buys

• It costs tokens: the discarded attempt was already billed.
• If the corruption is deterministic for a given request, the retry fails the same way and the turn ends as it does today — you will have spent one extra attempt to learn that. mode: observe for a day distinguishes the two cases before the retry is trusted with budget: it counts exactly what guard would do and retries nothing, and {{malformedToolJsonGuard}} serves a read-only snapshot of those counters plus the plugin's own blind spots.
• Repeating the step has no side effect to undo: JSON.parse fails before the assistant message exists, so no tool ran and no assistant message was appended, and the only trace of the discarded attempt is its own assistant/attempt record.

What I measured

I drove each of the 10 published lines this package claims — 0.1.7-rc.2 through 0.2.1-rc.2, all of which are admitted by its peer range under both semver readings and which is the complete set the range admits — through its own shipped adapter against a loopback Messages endpoint, and folded the chunks it actually produced into the plugin's own classifier: 10/10 produce MALFORMED_RESPONSE after emitting the tool-call block-end, and the classifier names the shape on all ten. Three controls are claimed on none of them: the same call with arguments that do close, the same truncation with stop_reason: max_tokens (pruned upstream, so no failure at all), and a text-only answer. The mutation suite over the classifier and the decision is 21/21 caught.

If you can run it with mode: observe and paste the counters, that would settle whether your corruption is per-response or per-request — which decides whether the retry recovers your turns or merely documents them.

[ltmroberthk915]

Thanks for the thorough reply — it was checkable end to end, and we followed it. Here is what we verified, what we found that differs from your build assumption, and what we already applied.

1. Your diagnosis checks out in the shipped 0.2.1-rc.2 app.asar

• translate(): JSON.parse(content.arguments) on message_stop, failure → malformed('tool input is invalid JSON') → MALFORMED_RESPONSE.
• DEFAULT_RETRYABLE_CODES = [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT] — indeed no MALFORMED_RESPONSE, so the asymmetry is real.
• retryableCodes: z.array(z.string()) in normalPolicySchema — configurable, as you said.
• Your three ruled-out causes: confirmed. parseSse uses body.pipeThrough(new TextDecoderStream()) (so a CJK character split across SSE frames reassembles), startBlock only overwrites with block.json when it is non-empty (Anthropic contract: empty input + deltas), and a truncated stream reaches throw new LlmError("DeepSeek Messages stream ended before message_stop", "STREAM_CLOSED").

2. We audited the plugin too

From a checkout of argszero/dsh-malformed-tool-json-guard: tsc builds clean, npm test is 66/66, the mount smoke test passes, and the classifier/decision logic is sound (both halves required, bounded per step, no disk writes, no repair).

Mutation arms: 21/21 caught, 0 survived — but we had to adapt the runner. scripts/inject-defects.mjs uses execFileSync('npx.cmd', …, { stdio: 'pipe' }), which does not work on Windows (execFileSync of a .cmd needs a shell) and our sandbox forbids capturing another process's piped stdio. Worth a shell: true / process.execPath + typescript/bin/tsc fix if you want the suite to be green on Windows.

3. The one-line knob is reachable on this released desktop build

Your note assumes the desktop route config is only in app.asar. On our install the session actually uses deepseek-account (plugin id llm-deepseek-account), and that plugin's Config spreads deepSeekConfigFields — which includes retryPolicy. Its bundle row carries no config, so a profile patch row with just retryPolicy replaces nothing and resets nothing. The account-route docs also state that edits to $DSH_HOME/profiles/<profile>/cordis.patch.yml take effect on the next request. So no overlay and no plugin were needed:

- id: llm-deepseek-account
  name: '@deepseek-ai/dsh-llm-deepseek-account'
  config:
    retryPolicy:
      mode: normal
      maxRetries: 2
      retryableCodes:
        - EMPTY_RESPONSE
        - RATE_LIMIT
        - SERVER
        - TIMEOUT
        - TRANSPORT
        - MALFORMED_RESPONSE

• Backed up the previous patch, appended the row, and it live-reloaded (no restart).
• Verified the route still works with two real calls after the change (OK, OK2).
• maxRetries: 2 rather than 5 on purpose: if the corruption is deterministic this is 3 attempts instead of 6, and it still distinguishes "per-response" from "per-request".

4. On the observe-mode request

We'll watch llm/retry-started in the session log and report whether the retry recovers the turn (per-response corruption) or fails identically (per-request). If we later want your per-shape counters, we'll mount the plugin in observe mode — installing into the Electron-managed desktop profile is the main cost, which is why the config row came first.

Two small doc nits: the README shows cordis.yml with an insert: list, while desktop users edit cordis.patch.yml with row-level patch entries; and the mutation suite's Windows path issue above.

Thanks again — the asymmetry argument is what made the fix obvious, and the plugin is a clean fallback for profiles whose provider row does carry config.