Bug + tested fix: truncated tool-call arguments permanently poison a session (llm-deepseek serializer)

[brianmswheart]

The bug: when a tool call'''s generation is truncated mid-arguments (or the model emits malformed JSON), serializeAssistant in packages/llm/llm-deepseek/src/serialize.ts replays block.arguments verbatim on every subsequent turn. Servers that re-parse tool calls while rendering the chat template then reject every later request of that session — vLLM with Expecting '\'','\'' delimiter and llama.cpp with [json.exception.parse_error.101] — so no retry can ever succeed and the session is permanently stuck in an error loop. Observed in production with a ~13.6k-char subagent tool call truncated mid-string.

The fix (tested): validate arguments with JSON.parse at serialization and substitute "{}" when unparsable; valid arguments pass through untouched. The paired tool result already records what happened, and previously-poisoned sessions become usable again on their next request.

Since PRs and issues appear to be closed on this repo, the full change (plus a regression test in tests/serialize.spec.ts; suite passes 28/28) is on this branch:
https://github.com/brianmswheart/deepseek-harness/tree/fix/sanitize-replayed-tool-call-arguments — happy to reformat it however contributions are meant to flow.

Written with assistance from Claude Code.

[Electricitysheep]

截断在 tool-call arguments 中间 → 永久污染会话——和 #739（reasoning 序列化省略）、#725/#1405（空 delta 覆盖）都是 llm-deepseek 序列化层的边界问题，rc 期这层 bug 集中爆发。

你带了测试修复很好，建议和 #739 合并成一份序列化层 bug 汇总给官方。手册侧我们把这批序列化坑都收进第 6 章坑位 + FAQ：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/06-advanced.md

[argszero]

Confirmed against master, and your fix targets the right spot. This is the second distinct poisoning path in the same file — worth bundling with #1449.

Source confirmation

packages/llm/llm-deepseek/src/serialize.ts:71-99 (serializeAssistant):

const toolCalls = message.content
  .filter(block => block.type === 'tool-call')
  .map(block => ({
    id: block.id,
    type: 'function' as const,
    function: { name: block.name, arguments: block.arguments },
  }))

block.arguments is replayed verbatim on every turn — no validation. Once a truncated/malformed argument string is durably in the session log, every subsequent request re-sends it, and any server that re-parses tool-call JSON rejects the whole request. Your diagnosis is exactly right, and the vLLM/llama.cpp errors you cite match the "server-side re-parse" failure mode.

Same file, second poison path

The same serialize.ts contains the other poisoning mechanism I verified earlier today in #1449:

• flattenText (:56-61) joins text blocks with zero lone-surrogate cleanup — an emoji-truncated tool result text poisons sessions the same way (lone surrogate → 400 on every resume).
• Your case: malformed tool-call arguments replayed by serializeAssistant.

Both are "content the server rejects → durably in the log → every later turn fails" — the same family as #1337's dangling tool_calls. It's worth treating all three as one "serializer/poison" workstream: validate/sanitize at serialization (your JSON.parse guard + a surrogate guard), and ideally a recovery pass for already-poisoned sessions.

On the fix

JSON.parse at serialization with "{}" fallback is the right minimal guard — it matches the "never let bad content reach the wire" principle, and the paired tool result already records what happened. Your regression test in tests/serialize.spec.ts (28/28) covers the right boundary. Since PRs are currently closed, a consolidated "llm-deepseek serializer hardening" post bundling your fix + the #1449 surrogate guard (as Electricitysheep suggests) would give maintainers one clean workstream to act on when the channel opens.