bug 任何会话只要遇到截断在 emoji 中间的工具结果，就会永久 400 无法继续

[bings1230]

工具输出截断时没有按 UTF-16 代理对边界切割，也没有在序列化前清洗孤立代理项（llm-deepseek/src/serialize.ts 的 flattenText 原样透传）。任何会话只要遇到截断在 emoji 中间的工具结果，就会永久 400 无法继续。

[Electricitysheep]

这 bug 挺阴的——截断在 UTF-16 代理对中间，emoji 直接被劈成两半，序列化层又不清理孤立代理项，会话就永久 400 了。和之前 unknown tool 那个（SSE 分块覆盖工具名）算是一类：都是"流式/截断的边界处理"问题，rc 期这种边界 bug 特别多。

暂时没太好的绕法（会话已经 400 的话只能开新会话），不过这类边界问题我们 FAQ 里汇总了一些同族案例和排查思路，可以参考：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/faq.md

[argszero]

定位准确，我对着 master 源码核实了：packages/llm/llm-deepseek/src/serialize.ts:56-61 的 flattenText 就是 .filter(text).map(block => block.text).join('')——没有任何孤立代理项（lone surrogate）清洗，截断在 emoji 中间产生的孤立半代理对会被原样透传到 wire。

机制补充：

1. 为什么是"永久 400"：工具结果一旦进入会话日志，每次 resume 都会把历史消息重新序列化发给上游——包含那个孤立代理项的消息永远在请求里，所以只要不修日志，这个会话每次都 400。这和 Community plugins resolving a second @deepseek-ai/dsh-tools copy crash the tool scheduler with Cannot read properties of undefined (reading 'prepare') #1337 里"tool_calls 悬空导致会话不可恢复"是同一类问题：会话日志里落了一个无法被模型 API 接受的内容，会话就永久中毒。

2. 修复位置建议：真正的修复应该做在截断/落盘边界（产出工具结果文本的地方）——如果截断点落在高位代理项后，把残留的高位代理项丢弃或替换为 U+FFFD（替换字符）。flattenText 里加清洗是 defense-in-depth（text.replace(/[\uD800-\uDFFF]/g, '\uFFFD') 或只清理未配对代理项），但根源在截断逻辑。

3. 恢复路径：已中毒的会话需要一个"清洗工具结果中的孤立代理项"的修复工具（离线改日志），与 BUG: 同一 DSH_HOME 下多进程并发写同一会话日志，导致 seq 重复、整段历史无法加载 #1452 里"损坏日志恢复工具"是同一类需求。SESSION_FORMAT_VERSION = 0 阶段改这个没有兼容负担。

如果你能提供截断发生处的代码路径（哪个工具/哪段输出），我可以帮忙定位具体的截断点在哪里——这决定修复该放在哪个层。

[bings1230]

DSH会话排障.md
我本人不是很懂代码开发，只能让ds自行整理了一个排障文档，可以参考一下

[duduking19]

I reproduced this issue on the current master commit 47f9438 and prepared a focused, tested patch.

Patch commit: duduking19@213de28

Branch: https://github.com/duduking19/deepseek-harness/tree/codex/fix-deepseek-malformed-utf16

Root cause

JavaScript strings can retain a lone UTF-16 surrogate when code-unit truncation splits an astral code point such as an emoji. flattenText() joined the message text blocks and forwarded the resulting string unchanged. JSON preserves the lone code unit as an escape, but a DeepSeek-compatible endpoint may reject the request. Once the malformed tool result is durable history, every later request replays it and can fail again.

Fix

The patch calls String.prototype.toWellFormed() after adjacent text blocks are joined.

Joining first is important: it preserves a valid surrogate pair whose two halves happen to occupy adjacent blocks, while isolated high or low surrogates become U+FFFD. The repair occurs only in the DeepSeek wire representation, so existing session logs become sendable without rewriting durable events or changing the session format. Producer-side code-point-aware truncation can still be added independently.

Verification

• The focused regression failed on unpatched master.
• DeepSeek serializer tests: 29 passed.
• serialize.ts coverage: 100% statements, branches, functions, and lines.
• Keyless assembled-application snapshot passed in source mode and built-lib mode.
• pnpm run lint: passed.
• pnpm run typecheck: passed, including the pre-push hook.
• pnpm run doc-sync: 28 gates passed.
• git diff --check: passed.

The patch also updates the bilingual package README and includes the required bilingual Agent Note. Since the repository currently does not accept external PRs, I am sharing the validated commit here for maintainers to incorporate if appropriate.

---

中文附注

我已在当前 master 提交 47f9438 上复现该问题，并准备了范围集中的完整补丁。

补丁提交：duduking19@213de28

分支：https://github.com/duduking19/deepseek-harness/tree/codex/fix-deepseek-malformed-utf16

根因

JavaScript 字符串按 UTF-16 代码单元截断时，可能把 emoji 等辅助平面码点从中拆开并留下孤立代理项。flattenText() 原先只拼接消息文本块，随后将该字符串原样发送。JSON 会把孤立代码单元保留为转义序列，但 DeepSeek 兼容端点可能拒绝该请求。畸形工具结果进入持久历史后，后续请求会反复重放它，从而持续失败。

修复

补丁先拼接相邻文本块，再调用 String.prototype.toWellFormed()。先拼接可以保留两半位于相邻文本块中的合法代理项对，只有孤立的高、低代理项会变成 U+FFFD。修复只作用于 DeepSeek 协议表示，不改写持久事件，也不改变会话格式，因此已有受影响会话可以直接恢复发送。各文本生产方仍可独立改用按码点截断。

验证

• 新增回归测试在未修复的 master 上稳定失败。
• DeepSeek 序列化测试 29 项全部通过。
• serialize.ts 的语句、分支、函数和行覆盖率均为 100%。
• 无密钥组装应用快照在源码模式和构建后的 lib 模式均通过。
• pnpm run lint、pnpm run typecheck、git diff --check 均通过。
• pnpm run doc-sync 的 28 项门禁全部通过。

补丁同时更新了中英文包文档，并包含仓库要求的双语 Agent Note。由于仓库目前不接受外部 PR，现将已验证的提交附在讨论中，供维护者评估和吸收。