[Bug Report] Streamed tool-call arguments with truncated JSON are persisted, then every subsequent turn fails with 400 INVALID_REQUEST: Unterminated string ... in the same session forever

[422505006]

Summary

When a model streams a tool call whose arguments payload arrives truncated / incomplete JSON (the delta stream stops mid-string, or a closing " / } never arrives before the block ends), the harness persists the malformed string verbatim into the append-only session log.

From then on, every request in that session rebuilds its history from the log, serializeAssistant reserializes the same broken arguments unmodified into tool_calls[].function.arguments, and the DeepSeek (Python) endpoint fails to json.loads it, returning:

400 INVALID_REQUEST: Unterminated string starting at: line 1 column N (char N)

The turn is marked failed and the GUI shows the terminal turn-error. Because the log is append-only and the bad record is never healed, the same session fails on every follow-up turn, indefinitely. Only starting a new conversation (fresh log, no bad history) recovers.

Environment

• GUI: DeepSeek Harness Web (http://127.0.0.1:3080/)
• Adapter: @deepseek-ai/dsh-llm-deepseek (DeepSeek chat-completions compatible endpoint, streaming)
• Persistence: session.jsonl.zstd (append-only JSONL back-end)
• Platform: Windows

Steps to reproduce

1. In a session, have the model issue a tool call (observed with read, grep, and pwsh; likely any tool) where the streamed arguments is cut off mid-JSON — the tool-call-delta stops before the closing "} and block-end closes the block anyway.
2. Observe that the truncated arguments is persisted as a tool/call event in the session log.
3. Send any follow-up message in the same session.
4. The turn fails with 400 INVALID_REQUEST: Unterminated string starting at: line 1 column N (char N).
5. Repeat — the same error recurs on every turn; the session never recovers.
6. A new conversation runs normally.

Expected behavior

• A tool call whose streamed arguments do not form valid JSON should either be rejected/retried at ingest time, or persisted in a sane form (e.g. {}), so that a single truncated stream does not permanently brick the session history.
• At minimum, the adapter must not resend unparseable arguments to a schema-strict upstream and turn it into a permanent 400.
• Existing corrupted records should be supported: a recovery/heal path on load() for malformed persisted arguments.

Actual behavior

The ingest path deliberately tolerates malformed arguments, but the resend path is strict, and nothing validates or heals in between:

1. BlockAssembler concatenates tool-call-delta.argumentsDelta onto the accumulating arguments (@deepseek-ai/dsh-llm, assembler.ts) without ever checking that the result is valid JSON.
2. dsh-agent-loop's parseArguments swallows invalid JSON (catch { return raw }) and runs the tool with the raw truncated string — no error surfaces.
3. session.append("tool/call", { arguments: block.arguments }) persists the raw truncated string as the authoritative record.
4. On later turns, dsh-llm-deepseek's serializeAssistant writes tool_calls[].function.arguments = block.arguments verbatim into the wire request; the DeepSeek server (Python) json.loads it and 400s.
5. Independently, dsh-host-apiproxy's viewFor / backscanArgs also do a bare JSON.parse(raw), throwing Unterminated string ... again — this is what emits the console noise api-proxy: presenter failed for tool/call, falling back to generic: ....
6. Session logs are append-only and load() only synthesizes missing tool/result/turn/end closers; it does not scan or heal malformed arguments. So the poisoned record is permanent.

Evidence (from real ~/.dsh session logs)

Example 1 — persisted tool/call with truncated read arguments:

{"type":"tool/call","seq":688,"data":{"name":"read","arguments":"{\"file_path\": \"C:\\...\\dsh-llm-deepseek\\lib\\types\\types.d.ts"}}

(note: missing closing "}), immediately followed by:

{"type":"assistant/chunk","seq":696,"data":{"chunk":{"type":"finish","reason":{"kind":"error","failure":{"message":"Unterminated string starting at: line 1 column 15 (char 14)","code":"INVALID_REQUEST","status":400}}}}
{"type":"turn/end","seq":698,"data":{"reason":{"kind":"error","error":{"message":"Unterminated string starting at: line 1 column 15 (char 14)","code":"INVALID_REQUEST","status":400}}}}

Example 2 — persisted tool/call with truncated grep arguments:

{"type":"tool/call","seq":169,"data":{"name":"grep","arguments":"{\"pattern\": \"chat_template_kwargs\", \"path\": \"C:\\...\\1e7f6d9597241db0"}}

followed by two turn/end errors (seq 175, seq 183) with Unterminated string starting at: line 1 column 45 (char 44).

The streamed deltas confirm the truncation is upstream: for example the read call received a single partial argumentsDelta and then block-end without a closing "}", while adjacent glob calls in the same assistant message did receive their closing "}" deltas — so the harness faithfully accumulated a payload the provider never finished.

Suggested fixes

• A (minimal, unblocks) — in dsh-llm-deepseek's serializeAssistant (and any other place that resends tool-call arguments), validate with JSON.parse and substitute {} for invalid values, so a poisoned history stops producing permanent 400s:

  function safeArguments(raw: string): string {
      try { JSON.parse(raw); return raw; } catch { return "{}"; }
  }

• B (quiet the noise) — wrap the bare JSON.parse(raw) in dsh-host-apiproxy viewFor / backscanArgs in try/catch (mirroring parseArguments elsewhere), removing the presenter failed ... falling back to generic console spam.

• C (root cause) — validate the accumulated tool-call arguments (valid JSON) before persisting the tool/call event (in BlockAssembler finalize or appendToolCall); drop or replace invalid arguments so bad history never enters the log. Optionally add a recovery/heal pass on load() for already-persisted malformed records.

Impact

• A single truncated streamed tool call permanently bricks the session: every later turn 400s with INVALID_REQUEST until the user branches or starts a new conversation.
• Server console pollution from the duplicated presenter failed JSON-parse errors on the same poisoned record.

---

Issue drafted from a diagnosis that inspected the compiled packages in the npm-cache checkout and decoded the local ~/.dsh/sessions/.../session.jsonl.zstd logs to confirm the persisted corrupt arguments and the recurring INVALID_REQUEST turn errors.

[zoahdev]

核验通过（对照 main/master HEAD 99f6f02 rc.7 TS 源码）——你描述的六步链路逐条成立，这是一个"单次截断流 → 会话永久砖化"的实锤 bug，且比报告更严重一处：截断参数不只是砖化历史，工具本身还带着垃圾参数真实执行了。

代码逐条确认：

1. packages/llm/llm/src/assembler.ts:72：partial.toolCallArguments += chunk.argumentsDelta——纯拼接，无 JSON 校验，block-end 前也不检查闭合；
2. packages/core/agent-loop/src/tool-calls.ts:104-108：parseArguments catch 返回 raw（"preserving invalid JSON as text"）——工具用截断串真实执行；
3. session.append('tool/call', { arguments: block.arguments })——raw 截断串作为权威记录落盘；
4. packages/llm/llm-deepseek/src/serialize.ts:82：function: { name: block.name, arguments: block.arguments }——逐字重发，无二次校验；
5. packages/host/apiproxy/src/api-proxy.ts:713-727 viewFor + :757-764 backscanArgs：裸 JSON.parse（soft-fall 到 generic view，产生你看到的 console 噪声）；
6. load() 只合成缺失 closers，不扫描/修复 malformed arguments——毒记录永久。

修复优先级（同意你的 A/B/C，微调排序）：

1. C 是根治，且落点应该更靠前：在 BlockAssembler finalize（assembler.ts:72 的累积点之后、block-end 之前）校验 JSON.parse(partial.toolCallArguments)——无效则拒绝该调用（标记 INVALID_ARGUMENTS 失败，重试或让模型重新生成），而不是"落盘畸形 + 让工具带着垃圾执行"。"工具用截断参数真实执行"是不可接受的静默风险（与你报告的永久 400 相比，这是更隐蔽的危害）。
2. A 是必要兜底：serializeAssistant 重发前 safeArguments（JSON.parse 失败 → {} 或抛带上下文的错误）——即使历史已有毒记录，新回合不再 400。
3. B 顺带修：viewFor/backscanArgs 的裸 parse 包 try/catch，去掉噪声；但这是观感问题，别让它在 PR 里稀释 C。
4. load() 愈合作为可选第四步：扫描历史 malformed arguments（能识别则 {} + 日志），与坏工件隔离族（[Bug Report] 单个会话日志损坏使 `session.list` 整体 500，Web 侧边栏全部会话消失且无界面提示 #1047 的"load 拒绝但不修复"）不同——这里是可确定性修复的数据，建议愈合而非仅隔离。

家族归类：并入家族 3（坏工件隔离）"截断 tool-call 参数"子族（与 #3232 崩溃恢复、#1047 单坏日志同原则：隔离 + 可见 + 可修复才修复）。需要的话我可以把 C 的验证点写成回归测试（截断 argumentsDelta → assembler finalize 拒绝/落盘正常形态）。

[denial123789]

I verified the durable failure chain against 99f6f02 and turned the operator-side containment/recovery path into an independent English runbook:

https://sandbaseai.github.io/deepseek-harness-handbook/poisoned-session-recovery.html

The practical recovery sequence is:

1. stop the active turn and avoid another Retry in the same Session;
2. use the Web header Session log export (the Host flushes before exporting);
3. keep the ZIP unchanged, then inspect a copy of its logical session.jsonl;
4. start a new conversation and carry over only minimal task context;
5. archive the poisoned Session instead of editing the live .jsonl.zstd.

One current-source nuance: at 99f6f02, backscanArgs already catches invalid stored arguments and soft-falls, while viewFor contains presenter/parse failures. That UI path can produce generic rendering/noise, but it is not the durable cause. The repeating 400 remains the verbatim value flowing through appendToolCall() and later serializeAssistant(). Crash-tail repair closes interrupted calls/steps/turns; it does not rewrite a committed malformed arguments string.

The runbook includes a read-only detector that parses the outer event row and then parses event.data.arguments separately, plus a minimal incident bundle for a regression case.