[Ideas] One malformed tool-call argument kills the whole turn: MALFORMED_RESPONSE/STREAM_CLOSED are not default-retryable (46 turns lost in production audit)

[Frank2015a]

Summary

When the model emits a tool-call whose arguments string is not valid JSON, the DeepSeek Messages adapter throws LlmError("DeepSeek Messages stream: tool input is invalid JSON", "MALFORMED_RESPONSE"), and the default retry policy does not include MALFORMED_RESPONSE — so a single bad sampling of tool arguments terminates the entire agent turn. In long-running sessions this surfaces as:

本轮运行失败 DeepSeek Messages stream: tool input is invalid JSON
MALFORMED_RESPONSE

… and the turn ends with reason.kind: "error".

Where

• packages/llm/llm-deepseek/src/translate.ts — at message_stop, every tool-call block's accumulated arguments is JSON.parsed; failure → malformed('tool input is invalid JSON') → MALFORMED_RESPONSE.
• packages/llm/llm/src/retry-policy.ts — DEFAULT_RETRYABLE_CODES = [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT]. No MALFORMED_RESPONSE, no STREAM_CLOSED.
• @deepseek-ai/dsh-llm-retry only retries codes in policy.retryableCodes (normal mode), so the failure is terminal.

The adapter README documents the asymmetry explicitly: "a terminal stop with no content blocks becomes EMPTY_RESPONSE, which the default retry policy retries" — but the other two stream-level failures are not retried.

Evidence from production use

Full-text audit of 961 compressed session logs on one long-running machine (dsh 0.2.0-rc.2, provider deepseek-account, macOS):

• 43 sessions contain the error, 220 occurrences of tool input is invalid JSON
• 46 turn/end events carry {reason: {kind: "error", error: {code: "MALFORMED_RESPONSE"}}} — i.e. 46 turns were killed by this
• Zero llm/retry events accompany those failures (confirming non-retryability)

Behavior verified identical on upstream master as of 2026-10-06 (code search on translate.ts + retry-policy.ts).

Why I think this is a transient, retryable failure

Malformed tool arguments are a sampling artifact of one completion, not a deterministic condition: the same request re-issued typically succeeds. The codebase itself already tolerates malformed tool arguments in other paths — serialize.spec.ts asserts historical tool-call arguments like '{', '', '[]' are coerced to empty input rather than rejected. EMPTY_RESPONSE — a similarly degenerate model-output failure — was deliberately made default-retryable for the same reason.

STREAM_CLOSED ("stream ended before message_stop") is arguably the same class: a mid-stream drop with a partial response.

Proposed fix (any of)

1. Add MALFORMED_RESPONSE (and consider STREAM_CLOSED) to DEFAULT_RETRYABLE_CODES.
2. Or narrower: give the translate-layer tool-JSON parse failure its own code (e.g. TOOL_ARGS_MALFORMED) that is default-retryable, keeping MALFORMED_RESPONSE for protocol violations.
3. At minimum, include the parse error plus a bounded snippet of the offending arguments in the error message/failure payload — today it is undiagnosable from logs alone.

Workaround (until fixed)

Per-provider config already supports it, since retryPolicy.retryableCodes is user-overridable (volatile, hot-reloaded via the profile patch):

- id: llm-deepseek-account
  config:
    retryPolicy:
      mode: normal
      maxRetries: 8
      retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT, MALFORMED_RESPONSE, STREAM_CLOSED]

Tested locally: resolveRetryPolicy accepts the extended list (positive + negative controls run), and the retry plugin then recovers instead of killing the turn.

[luoyukun3-oss]

Confirmed on the released line (0.1.7-rc.2), plus something that may make this solvable without a
kernel change.

The two codes are not one adapter's quirk. In addition to the DeepSeek sites you cite
(dsh-llm-deepseek/lib/index.js:1798 → MALFORMED_RESPONSE, :2002 → STREAM_CLOSED), the pi-ai
adapter raises the same class: dsh-llm-pi-ai/lib/index.js:1601
throw new LlmError("pi-ai event stream ended without done/error", "STREAM_CLOSED"). So the decision
lives in the shared policy, not in one provider.

There is a mode: "always" policy you may be able to use today.
dsh-llm/lib/types/retry-policy.js:34-37:

const alwaysPolicySchema = z.object({
    mode: z.const("always").required(),
    backoff: backoffSchema,
});

and :39 unions it with the normal policy. In always mode there is no code list at all — the policy
does not consult retryableCodes, so MALFORMED_RESPONSE would be retried without touching the
defaults. The config field is retryPolicy on the provider options (dsh-llm-deepseek:333 /
:446, dsh-llm-pi-ai:1044 / :1140), and it is validated by resolveRetryPolicy().

If you prefer the narrower route, mode: "normal" with
retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT, "MALFORMED_RESPONSE"]
(:31 defaults to exactly that first list) keeps every other code terminal.

One caveat for the proposal: the non-retryability of STREAM_CLOSED may be pinned by a test rather
than merely omitted. A related thread (#7123) cited transport-recovery.spec.ts:178 as asserting
that code is non-default-retryable. I could not verify that file myself — it is not shipped in the
published package — so treat it as a lead. If it holds, adding the code to the defaults means changing
that assertion as well, which is an argument for keeping STREAM_CLOSED in its own section rather than
bundling it with MALFORMED_RESPONSE.

Two numbers that would strengthen the case a lot, if you have them:

1. For the 46 killed turns — how often does re-issuing the same request succeed? Your argument rests
   on malformed arguments being a sampling artifact ("typically succeeds"), and a success rate turned
   into a number would settle it. Right now it is the one claim in the report without a measurement
   behind it.
2. Do you have any STREAM_CLOSED instances in that same audit, counted separately? Your 220
   occurrences are all tool input is invalid JSON; if STREAM_CLOSED never appears in those 961
   logs, that is itself worth stating — it would show the two codes have very different frequencies and
   should not be given equal weight in the fix.

[Frank2015a]

Update — ready-to-apply patch. A fix branch is up on a public fork:

• Branch: Frank2015a/deepseek-harness@fix/default-retry-stream-failures (commits fe2c19e + d719982, based on today's master 5badb15)
• Scope: adds MALFORMED_RESPONSE + STREAM_CLOSED to DEFAULT_RETRYABLE_CODES in packages/llm/llm/src/retry-policy.ts, with the matching expectation updated in packages/llm/llm/tests/retry-policy.spec.ts
• My token lacks PR/issue creation permission on this repo (403/404 on both GraphQL and REST), so I can't open the PR myself — the branch is public, so opening a PR from it is one click for anyone with write access.

Post-fix field result from the same production machine (2026-10-06): two real occurrences of tool input is invalid JSON (13:08:27, 13:33:37) were retried and both turns completed, instead of dying like the 46 turns before the mitigation.

Ready-to-apply diff

--- a/packages/llm/llm/src/retry-policy.ts
+++ b/packages/llm/llm/src/retry-policy.ts
@@ -14,11 +14,19 @@ const DEFAULT_JITTER_RATIO = 0.1
 const DEFAULT_RETRYABLE_CODES = Object.freeze([
   EMPTY_RESPONSE_CODE,
   'RATE_LIMIT',
   'SERVER',
   'TIMEOUT',
   'TRANSPORT',
+  // Stream-level degenerate completions: a malformed tool-call argument is a
+  // sampling artifact of one completion (the identical request typically
+  // succeeds on re-issue), and a stream that ends before message_stop is the
+  // same transient class as TRANSPORT/TIMEOUT. Terminating the turn on the
+  // first occurrence converts a one-off model hiccup into a user-visible
+  // failure of the whole agent turn.
+  'MALFORMED_RESPONSE',
+  'STREAM_CLOSED',
 ])

--- a/packages/llm/llm/tests/retry-policy.spec.ts
+++ b/packages/llm/llm/tests/retry-policy.spec.ts
@@ -13,7 +13,9 @@ it('resolves the default policy', () => {
       mode: 'normal',
       maxRetries: 5,
-      retryableCodes: ['EMPTY_RESPONSE', 'RATE_LIMIT', 'SERVER', 'TIMEOUT', 'TRANSPORT'],
+      retryableCodes: [
+        'EMPTY_RESPONSE', 'RATE_LIMIT', 'SERVER', 'TIMEOUT', 'TRANSPORT',
+        'MALFORMED_RESPONSE', 'STREAM_CLOSED',
+      ],
       initialDelayMs: 500,
       maxDelayMs: 10_000,
       jitterRatio: 0.1,

[ztan4706]

Independent confirmation on Windows / dsh-desktop 0.2.1-rc.3, plus the two numbers you asked for

Hit the same failure today (2026-10-25 10:50:17 +08:00) on a Windows box running the desktop build (0.2.1-rc.3, bundled runtime, built 2026-10-23), provider deepseek-account, model deepseek-flash. Same code path, and the shape was even more degenerate than "invalid JSON": the tool-call block arrived with a completely empty argument payload.

The recorded stream for the failing step (assistant/attempt → stream in the session log):

json

{"type":"chunk","chunk":{"type":"block-start","index":0,"blockType":"reasoning"}}
{"type":"reasoning-chunks","index":0,"dt":[...826 deltas...]}
{"type":"chunk","chunk":{"type":"block-end","index":0}}
{"type":"chunk","chunk":{"type":"block-start","index":1,"blockType":"tool-call"}}
{"type":"tool-call-chunks","index":1,"id":"call_00_BcmSgOQmugiA6y2EskkE2550",
"name":"schedule_create","args":[""]}
{"type":"chunk","chunk":{"type":"block-end","index":1}}
{"type":"chunk","chunk":{"type":"finish","reason":{"kind":"error","failure":{
"message":"DeepSeek Messages stream: tool input is invalid JSON",
"code":"MALFORMED_RESPONSE"}}}}
turn/end then carried the same failure. The turn had already completed 3 steps / 8 tool calls and had emitted no assistant text; from the user's side the conversation simply died with the red error.

The two numbers you said would strengthen the case:

Re-issue success rate: 1/1. ~80 s later, in the next turn, the identical tool call with identical arguments succeeded — no config or code change in between. Small n, but the direction matches your "sampling artifact" hypothesis.
STREAM_CLOSED: 0 killed turns. Full-text audit of all 93 session logs on this machine: turn/end with MALFORMED_RESPONSE = 1 (the above); with STREAM_CLOSED = 0. Other turn-killing codes present: UNKNOWN ×3, NO_ADAPTER ×1, TRANSPORT ×1. On this machine the two codes differ in frequency by a lot, which supports your instinct not to give them equal weight.
So the bug is alive on 0.2.1-rc.3, not only on 0.2.0-rc.2.

We have applied your config-level workaround through the profile patch (mode: normal, maxRetries: 8, retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT, MALFORMED_RESPONSE]). The entry comes up active and the projected Config schema accepts exactly those keys, so the override is in place — but we cannot prove recovery until the next malformed stream arrives. I will report back when it does.

One addition to your "diagnosability" point: keeping the parse error plus the first ~200 bytes of the offending arguments in the failure payload would separate empty from truncated from wrong shape from the log alone. In our case it took a raw zstd session-log dig to establish which one it was.

[hoyin-law]

在 0.2.1-rc.5（Desktop 2.0.17，Windows 11） 上重新确认该问题仍复现：2026-10-28→30 共 2 次 tool input is invalid JSON（ask_user 参数末尾多 }、memory 长中文串 。".target" 错位），失败前后 llm/retry 事件 0 条；同会话同日 SERVER 被自动重试 5 次并恢复。完整证据与根因行号已汇总到 #11577：#11577

这里的补丁分支（Frank2015a/deepseek-harness@fix/default-retry-stream-failures，d719982）应仍可直接应用：packages/llm/llm/src/retry-policy.ts 自 2026-08-18 未再变更，packages/llm/llm/tests/retry-policy.spec.ts#L16 也仍期待 5 个默认码。

恳请维护者合入或给出目标版本；如果担心整步重试会连坐同一步里其它正常工具调用（#9402），可先只对“全部 tool-call 参数不可读且无 text/reasoning 伴随”的场景启用，正解思路（非致命工具错误 + 模型同轮自我修订）见 #11577。

[Roshenn]

同一份字符级证据已贴在 #11577