[bug] 打开大会话时 history 页把全部 assistant/chunk 送进浏览器，UI 看起来像没回复 — 附可 cherry-pick 修复

[ericcaiwx-star]

摘要 / Summary

session.history 按追加来源的 user/message / assistant/message 计数分页，但返回该裁切内的全部原始事件。生产环境的 assistant/message 会在 sourceEventSeqs 列出整段 assistant/chunk token 流，一次编程回合就能有数千条分片。于是默认 50 条（甚至只请求 20 条）消息的尾页会变成上万个事件、数兆字节。

Web 客户端 session.open 要等这页返回才把 openState 翻成 open。请求进行期间实时 session/event 被缓冲，转录看起来冻结：点开旧会话失败，或发出「你好」像没有回复。宿主其实已经在数秒内跑完 turn。

session.history pages by append-origin message count, then returns every raw event in that cut. A production assistant message lists its assistant/chunk seqs in sourceEventSeqs, so one coding turn can add thousands of chunks. A 20-message page measured 12,780 events / 2.4MB and took ~3.5s locally; over high-latency Tailscale the browser never finishes folding. session.prompt still succeeds on the host.

复现 / Repro

1. 跑一个有大量流式输出的编程会话（工具调用 + 长回复），日志到数万事件 / 十余 MB。
2. 用 Web UI 打开该会话，或在已打开状态下再发一条短消息。
3. 实际：侧栏标题在，对话区空白或停住；短消息像没回。session.history（maxMessages: 20）返回上万 assistant/chunk。
4. 期望：尾页只带已完成的 assistant/message（以及进行中步骤的分片），打开和后续 turn 立即可见。

对照：空白新会话工作正常；同一条 session.prompt 在宿主日志里有完整 assistant/message。

根因 / Root cause

packages/host/apiproxy/src/api-proxy.ts 的 paginate() 按消息边界裁切后，historyPage 原样送达整段 raw range。磁盘上的 packChunks（text-chunks 行）在读取时已经解码成逐条 assistant/chunk。客户端 PAGE_MESSAGES = 50，doOpen 在 history() 完成前不会安装窗口。

这不是 mux / WebSocket 升级失败：实时通道仍是 101，问题是历史页体积 + 打开路径。

修复 / Fix (cherry-pick ready)

• 分支：https://github.com/ericcaiwx-star/deepseek-harness/tree/fix/history-omit-settled-chunks
• commit：833140a63a — fix(apiproxy): omit settled assistant/chunk events from history pages
• 对比：master...ericcaiwx-star:deepseek-harness:fix/history-omit-settled-chunks

historyPage 仍按消息边界裁切（compaction 的 sourceEventSeqs 分组不变），然后去掉其追加来源 assistant/message 已在本页上的内部 assistant/chunk。进行中步骤（还没有最终消息）保留全部分片。原始裁切的首尾事件保留，因此客户端 beforeSeq 与实时尾 seq 缺口检查仍指向同一区间。实时 mux 帧不变。

验收 / Acceptance

pnpm exec vitest run packages/host/apiproxy/tests/api-proxy-view.spec.ts 通过。已完成步骤不再送达内部 chunk；进行中步骤保留 chunk；maxMessages: 1 时原始裁切首个 chunk 仍在，用该 seq 做 loadOlder 不会把已省略的内部分片再送一遍。

[ylwl1997]

session.history 只按消息条数分页（默认 50），但一页会带上整段 assistant/chunk。一次编程回合就能到上万事件 / 十几 MB，Web 的 30s unary 直接 abort，于是看起来像「没回复」、模型选择器也不出来。rc.7/rc.8 只修了分页栈溢出，这条还在。#1706 / #3726 是同一条。

先不要再点开那个大会话：新开一个 session 继续。旧日志还在 ~/.dsh/sessions/<id>（含 .jsonl.zstd），没有丢。Cherry-pick 那份 omit settled assistant/chunk 只影响自己的构建；npx / 全局安装不会吃到。

[ericcaiwx-star]

感谢指到同一条症状。#1706 / #3726 / #2119 / #2654 报的都是「一页 history 被 assistant/chunk 撑爆」；#1706 建议加单页事件上限。更早、方向相同的完整实现是 #2598（dingdingfox，分页前丢掉全部 assistant/chunk，并放宽客户端 loadOlder）。

这条不是重复贴同一份补丁。相对 #2598，这里多了三处，所以先不关：

1. 进行中的步骤仍带分片。 打开会话时如果最后一轮还没 assistant/message，历史页还能画出半截回复；性能优化提案：历史加载剔除流式分块事件（附完整实现与测试） #2598 在分页前滤掉所有 chunk，进行中前缀要等 live mux。
2. 客户端协议不动。 原始裁切的首尾事件留下，现有 beforeSeq（events[0].seq）和实时尾 seq 缺口检测仍指向同一区间，不用改 loadOlder。
3. 先按消息边界裁切，再丢掉已完成步骤的内部 chunk。 compaction 的 sourceEventSeqs 分组还在完整 raw range 上算；只省略已经有追加来源 assistant/message 的内部 assistant/chunk。

实时 mux、磁盘日志、导出都不变。Maintainer 可以直接 cherry-pick 这条，或在 #2598 上收这三处。

---

Same symptom as #1706 / #3726 / #2598. Keeping this thread open because the patch differs from #2598: keep in-progress chunks, leave the client beforeSeq / tail-seq contract unchanged, and omit only interior chunks of already-settled steps after the message-boundary cut.

[linxhen-ux]

补充一个更底层的相关案例（attach 解码路径，传输层修复覆盖不到）。

Related discussions（同一根源：chunk 全量物化）

• History payload bloat: a ~50-message page returns ~270k stream-delta events (~64 MB) #2654 — History payload bloat：~50 条消息页返回 ~270k 流式事件 / ~64MB
• Bug: session.history tail page returns unbounded payloads with high reasoning effort (27k events / 5.1 MB → main-thread freeze) #2119 — session.history 尾页高 reasoning effort 下无界载荷（27k 事件 / 5.1MB → 主线程冻结）
• 性能优化提案：历史加载剔除流式分块事件（附完整实现与测试） #2598 — 性能优化提案：历史加载剔除流式分块事件（附完整实现与测试）
• Web host TTFT climbs to 50-170s under any sessions that has subagent fan-out / mature sessions - three measured contributors (host-side, not gateway) #3235 — Web host TTFT 涨到 50-170s（subagent 扇出 / 成熟会话，三个已测因素）
• [bug] Failed streaming attempt's assistant/chunk events become orphan log data after retry (phantom replay content, double token counts) #661 — Failed streaming 的 assistant/chunk 变孤儿日志（幻影重放内容、重复 token 计数）
• [Docs] Generated persistence catalog omits the packed chunk rows that packChunks writes to the log #3458 — Docs：持久化目录漏掉 packChunks 打包行

以上都聚焦 history 传输 / UI 渲染 层。下面这个案例是更底层的 attach 解码路径：即使 history 不再送 chunk 进浏览器，会话打开时仍会全量解码展开，导致内存爆炸与 GC 停顿——现有修复覆盖不到。

现象

单会话 94.9MB（session.jsonl.zstd）内含 819 万事件，其中 819 万是流式 chunk（占 99.4%，逻辑事件 824 万、保留事件仅 5.2 万）。每次 attach/打开该会话：

• 解码时全量展开 chunk → Node 堆 4GB → GC 停顿 30-60s
• RPC 30s 超时（signal timed out），任务中断
• 客户端 Tauri supervisor 探活 60s 无响应判定 zombie → 内核被重启（现象 = 内核反复重启，看起来像崩溃）

实测数据（同会话，删除 chunk 后对比）

指标	原始（819 万 chunk）	slim 后（5.2 万事件）
解码耗时	4707ms	446ms（10.5×）
foldSurface	445ms	6ms
内核内存	4GB	781MB
打开会话	30-45s 或超时	<1s

reasoning 完整保留在 assistant/message 的 data.message.content[{type:"reasoning"}]，删 chunk 零内容丢失。

建议

1. 解码 lazy/按需：attach 时不展开 chunk（只在轨迹回放/计费审计时按需读取）——治本
2. 支持修剪被 compaction shadowed 的旧 chunk：token-meter 对 sourceEventSeqs === undefined 走保守路径（实测不报错），删旧 chunk + 重映射 seq 安全
3. 已落地实现参考：dsh-session-slimmer 的 slimSessionText（删 chunk 行 + oldSeq→newSeq 连续重编号 + 删 assistant/message 的 sourceEventSeqs + 重映射 surfaceOp/shadowedRange/shadowedSeqs + 验证 seq 连续与 surface 等价）

[ericcaiwx-star]

感谢补充 attach 解码路径的案例和实测数据，这条和 #3797 的 history 分页修复是同一 symptom 家族、不同层——值得单独跟进。

边界对齐

本帖 cherry-pick 的 omit settled assistant/chunk 只改 session.history 分页响应：在按消息边界裁切之后，省略已有 append-origin assistant/message 的步骤内部 chunk；进行中的 chunk、raw cut 首尾事件、live mux、磁盘日志都不动。

它碰不到你描述的 attach / open / resume 侧：persistence.inspect → agents.resume 仍会把整段 log（含全部 chunk）解码进 Host 内存。所以即使 history 不再把 chunk 送进浏览器，94.9MB / 819 万 chunk 那种会话在打开时仍可能 OOM、GC 停顿、30s unary 超时，乃至 supervisor 判 zombie 重启内核——这不是 #3797 能覆盖的。

对你三条建议的看法

1. attach 时 lazy/按需解码 chunk — 治本方向，但需要明确哪些 consumer 在 attach 路径上真的需要展开 chunk（foldSurface、compaction sourceEventSeqs、token-meter 等），否则容易和「model-visible ⟺ logged」的投影假设打架。
2. 修剪被 compaction shadow 的旧 chunk — 和 性能优化提案：历史加载剔除流式分块事件（附完整实现与测试） #2598 / [Bug] Web GUI cannot open very large sessions — session.history pages are unbounded by event count #1706 同族，但要证明 seq / surface / shadowedRange 重映射后审计与 replay 仍等价；你给的 token-meter 保守路径 + slim 前后对比很有用。
3. dsh-session-slimmer — 作为离线急救合理（先让会话能再打开），不应替代 runtime 侧的按需读取。

建议的后续拆法

• 传输/UI 层（本帖）：history 分页 omit settled chunks — 已附 fork branch，maintainer 可直接 cherry-pick。
• open/resume 层（你这条）：attach lazy decode 或 resume 时不全量物化 chunk — 建议单独开 discussion / issue，附上 819 万 chunk 的复现指标和你表格里的 slim 对比；必要时和 [bug] Failed streaming attempt's assistant/chunk events become orphan log data after retry (phantom replay content, double token counts) #661（孤儿 chunk / 幻影重放）一起看 packChunks 写入策略。

如果你愿意，可以把 slimSessionText 的核心 invariant（seq 连续、surface 等价、reasoning 保留在 message）整理成 maintainer 可 review 的 checklist，我可以帮你挂到新帖里。

---

Same symptom family, different layer: this thread’s patch trims settled interior chunks from session.history pages only; it does not change full-log decode on attach/resume. Lazy decode and offline slim are valid follow-ups — worth a separate thread with your benchmark table.

[linxhen-ux]

好的，checklist 如下，麻烦你挂到新帖里，需要补充复现数据或验证随时叫我。

slimSessionText invariant checklist（maintainer 可 review）

范围

• 仅删 chunk 行（text-chunks / reasoning-chunks / tool-call-chunks 打包行 + assistant/chunk 单行），其余事件与 header 原样保留

seq 重编号

• 保留事件 oldSeq→newSeq 连续重编号，输出 seq 严格 +1 递增、无空洞（内部 pass 4 校验）

seq 引用重映射（5 类字段）

• 顶层 seq
• sourceEventSeqs：assistant/message 的 chunk provenance → 删除（token-meter 对 undefined 走保守路径，实测不报错）；compaction/summary 的（引用 surface 节点）→ 重映射
• surfaceOp.start / surfaceOp.end
• data.shadowedRange.start / .end
• data.shadowedSeqs
• 引用已删 chunk → 硬失败（mapSeq 抛错），绝不静默

内容保留

• reasoning 完整保留在 assistant/message 的 data.message.content[{type:"reasoning"}]
• 正文 text、工具参数（tool/call + tool/result）不动

surface 等价（内核权威验证）

• foldSurface 对比：slim 前后 surface nodes 数量一致（98=98）
• replacements 数量一致（309=309）

帧级约束（DSH 硬性要求）

• 第一帧 = 恰好一行 header（assertZstdHeaderFrame 契约）
• 每帧以 \n 结尾（避免 torn JSONL record）
• 8MB 行边界分帧、原子写（临时文件 + rename）

实测数据（生产环境单会话，约 900 轮对话）

• 94.9MB / 819 万事件（99.4% 为流式 chunk）→ 15MB / 5.2 万事件
• 解码 4707→446ms（10.5×）、fold 445→6ms、内存 4GB→781MB、打开 <1s
• reasoning 完整保留在 assistant/message 的 data.message.content[{type:"reasoning"}]，删 chunk 零内容丢失

[ericcaiwx-star]

@linxhen-ux 感谢 checklist — 已按你 8/24 建议单独开帖挂 invariant，避免和 #3797 的 history 分页修复混在一起：

→ #4544 attach/resume 全量解码 chunk 致 OOM/超时

checklist 原文已迁入 #4544（署名 @linxhen-ux）。#3797 仍只管 session.history omit settled chunks；open/resume attach 层 + offline slim 另线推进。

---

@linxhen-ux: checklist moved to #4544 (attach/open-resume layer). #3797 stays scoped to history pagination only.