[Bug] 强制上下文压缩会损坏会话日志：seq 空洞 + 悬空 sourceEventSeqs 导致历史永久无法加载

[LucasWXSB]

声明：本文档由 DeepSeek Harness 中的 DeepSeek V4 Flash 模型生成，并由该模型自主完成缺陷排查与修复

DeepSeek Harness 0.1.0-rc.6 —— 任何在体积较大时被压缩过的会话，重启 host 后都无法再打开（"history unavailable"）。数据在磁盘上完好，但会话无法通过校验。已验证根因在压缩写入路径（折叠事件时未重排 seq / 未重映射溯源引用），而非存储层。

环境

字段	值
DSH 版本	0.1.0-rc.6（dsh web profile，npm @deepseek-ai/* 包均为 0.1.0-rc.6）
Node	v24.15.0
操作系统	Windows 11
会话规模	强制压缩（/compact 命令）时约 800k 上下文 token
涉及包	@deepseek-ai/dsh-session-persistence-jsonl、@deepseek-ai/dsh-session、@deepseek-ai/dsh-compaction、@deepseek-ai/dsh-llm-deepseek

摘要

被压缩过的大会话在 host 重启后无法再加载。打开时显示：

history unavailable for session "session-...": Error: corrupt session log: seq gap in committed region at line 33577 (expected 607335, got 607332)

绕过第一处失败后，后续校验错误继续暴露：

invalid seed event at index 685692: sourceEventSeqs must reference earlier events: 696619 >= current seq 685692

而当日志被修复到可以继续聊天时，消息重建仍可能在 provider 端失败：

Error from provider (Console Go): An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id',
The following tool_call_ids did not have response messages: call_00_eaD6ogYyrP2rVa2M9zmf5887

三个症状同源于一个根因：压缩事务折叠/删除了事件，但没有重排剩余事件的 seq，也没有重映射 sourceEventSeqs / surfaceOp.replace 引用，最终产出一份连加载器自己都拒绝的日志。

复现步骤

1. 运行一个会话直到上下文很大（我们达到约 800k token）。
2. 强制压缩（/compact）。
3. 重启 host（dsh web）或在新 host 进程中打开该会话。
4. 会话以 seq gap in committed region 错误打开失败（见上）。

我们没有观察到任何恢复路径：会话在之后每次打开时都保持损坏状态。

期望 vs 实际

• 期望：压缩在缩减上下文的同时保持会话日志可加载；压缩后的会话重启后能正常打开。
• 实际：压缩后的会话日志通不过加载器自身的 seq 连续性校验；手动重编号后又通不过溯源校验；修复完这些后，消息重建仍可能产生未配对的 tool_calls/tool-result 序列，被 provider 以 HTTP 400 拒绝。

根因分析

1. 加载器要求 seq 从 0 全局连续，但压缩留下了空洞

@deepseek-ai/dsh-session-persistence-jsonl/lib/index.js（约 L275–300）中的 SessionLogScanner.consumeEventLine 用运行计数校验每个解码事件：

const rowStart = this.events.length;
for (const event of decoded) {
    if (event.seq !== this.events.length) {
        const expected = this.events.length;
        this.events.length = rowStart;
        this.issue = new Error(`corrupt session log: seq gap in committed region at line ${this.eventLine} (expected ${expected}, got ${event.seq})`);
        if (decoded.some((candidate) => candidate.type === "turn/end")) throw this.issue;
        return;
    }
    this.events.push(event);
}

因此每个存储事件的 seq 必须等于其在日志中的位置。压缩用一个摘要节点替换一段 surface 区间（@deepseek-ai/dsh-compaction/lib/index.js L171–172："successful run replaces the selected surface span with one summary node"），这会删除事件——但区间之后的事件保留了原来的 seq，留下空洞。加载器随即报告 seq gap in committed region。

直接证据（没有任何外部工具碰过该文件）：首次故障出现后立即快照的原始备份（22:27，任何修复尝试之前）在 88,700 行中已包含 1,415 个 seq 空洞；最后一个存储的 seq 是 1,594,552，而首个空洞之前只有 1,561,208 个事件。该文件由 DSH 自己写入（压缩 + 后续追加）——它自己的加载器却拒绝读取。

第二个会话表现出同样的模式：3,950 个空洞；首个空洞之前有 607,335 个连续事件，而尾部事件携带的 seq 为 705,765。

2. 压缩未重映射溯源引用（sourceEventSeqs、surfaceOp.replace）

@deepseek-ai/dsh-session/lib/types/surface.js（约 L150–180）中的 assertProvenance 要求 sourceEventSeqs 中的每个条目都指向更早的事件：

if (nonEarlierSource === undefined && source >= event.seq) nonEarlierSource = source;
...
if (nonEarlierSource !== undefined) {
    throw new Error(`sourceEventSeqs must reference earlier events: ${nonEarlierSource} >= current seq ${event.seq}`);
}

重编号（我的修复）之后，在原编号下合法的引用变得非法：invalid seed event at index 685692: sourceEventSeqs must reference earlier events: 696619 >= current seq 685692。在修复后的会话中，675,246 个 sourceEventSeqs 条目全部引用压缩前的 seq 编号；其中 675,245 个干净地重映射成功，1 个引用了被压缩完全折叠掉的事件（悬空）。另有 4 处 surfaceOp.replace 区间的 start/end 需要重映射。

3. 压缩可能留下孤立的 tool/result，随后破坏消息重建

压缩边界切断了 tool 往返：assistant/message（含 tool_calls）和 tool/call 被折叠，但 tool/result 行幸存。回放时，@deepseek-ai/dsh-llm-deepseek/lib/index.js（约 L70–98）中的 serializeMessages 把每个 tool-result 块变成独立的 {role:"tool"} 线上消息；由于缺少前置的 assistant tool_calls，provider 以 HTTP 400 拒绝请求（The following tool_call_ids did not have response messages: call_00_…）。这是同一压缩 bug 的第二种表现（配对平衡检查存在于 dsh-compaction/lib/index.js L42–43，但我们的数据中折叠边界仍然产出了未配对的 result）。

影响

• 每个被压缩的大会话在重启后都变得不可读——压缩本是长会话的预期缓解手段，于是长会话变得不可用。
• 数据没有丢失（事件仍在磁盘上）；完整的重编号 + 引用重映射可以无损恢复对话。但用户没有官方支持的修复途径。
• 故障只在打开时被发现，此时压缩已经写入——压缩写入时没有任何校验能在提交前发现非法日志。

建议修复

1. 折叠后重编号：压缩替换 surface 区间后，重排所有剩余事件的 seq 使其从 0 全局连续，或让压缩事务重写日志尾部。
2. 重映射溯源：压缩期间/之后，把每个 sourceEventSeqs 条目和 surfaceOp.replace 的 start/end 重映射到新编号；丢弃（或记录）指向被折叠事件的引用。
3. tool 配对保证：确保折叠边界保持 tool 配对平衡（dsh-compaction 中已有平衡检查——将其作为写入日志的硬性不变量强制执行，而不只是内存检查），和/或让消息重建跳过未配对的 tool-result 块，而不是发出非法线上序列。
4. 写入时校验：压缩事务后运行与加载器相同的 scanLog/校验，若日志不可加载则回滚或标记会话，而不是提交一份无法加载的日志。
5. （可选）提供修复命令（dsh session repair），对现有日志执行重编号 + 重映射——目前受影响会话的用户没有任何恢复手段。

临时方案（我们的恢复方法，已验证有效）

一个独立修复脚本，对每个会话日志：

1. 按 magic（0xFD2FB528）定位每个 zstd 帧并逐帧解压（zstdDecompressSync），因为日志是拼接帧容器（原文件 53,327 帧；内置流式解压器只解码第一帧）；
2. 把每个事件的 seq（以及打包 chunk 行的 seq0）重写为全局连续的 0..N 序列，逐字保留行内容；
3. 通过 old→new seq 映射重映射每个 sourceEventSeqs 条目和 surfaceOp.replace 的 start/end；丢弃悬空引用（当非 assistant/message 事件上的 sourceEventSeqs 字段清空时整个删除该字段）；
4. 以 [frame0 = header][frame1 = all events] 重新编码，带 ZSTD_c_checksumFlag（与持久化层使用的参数相同）；
5. 用与加载器完全一致的语义从磁盘验证：0 空洞、0 溯源错误。

结果（两个会话现已正常打开并持续可用）：

会话	修复后事件数	验证
session-f889db13-…	695,462（用户继续聊天期间增长）	0 空洞、0 溯源错误
session-ac5bd0cc-…	1,594,969	0 空洞、0 溯源错误

所有中间状态的备份均保留在磁盘上；没有任何消息内容丢失（只丢失了压缩本身折叠掉的事件）。

附录 —— 观察到的确切错误串

history unavailable for session "session-f889db13-6662-4dff-810f-ed83725422c0":
Error: corrupt session log: seq gap in committed region at line 33577 (expected 607335, got 607332)

history unavailable for session "session-ac5bd0cc-55d2-46ab-b2fd-926377a20ef4":
Error: corrupt session log: seq gap in committed region at line 87285 (expected 1561208, got 1561205)

SessionPersistenceCorruptionError: stored session "session-f889db13-…" failed validation:
Error: invalid seed event at index 685692: sourceEventSeqs must reference earlier events: 696619 >= current seq 685692

Error from provider (Console Go): Upstream request failed: [invalid_request_error]
An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id',
The following tool_call_ids did not have response messages: call_00_eaD6ogYyrP2rVa2M9zmf5887

---

中文摘要

问题：DeepSeek Harness 0.1.0-rc.6 中，对 ~80 万 token 的大会话执行强制上下文压缩（/compact）后，重启 host 再打开该会话会报 seq gap in committed region 等错误，历史永远无法加载。

根因（代码级证据）：压缩事务（@deepseek-ai/dsh-compaction）用 surface replace 把一段历史折叠成一个摘要节点，但没有重排剩余事件的 seq 编号，也没有重映射 sourceEventSeqs / surfaceOp.replace 引用。而加载器（dsh-session-persistence-jsonl 的 SessionLogScanner）要求事件 seq 必须从 0 全局连续，校验引用必须指向更早的事件——因此 DSH 自己写出的压缩日志，自己的加载器拒绝读取。

三个症状同一根源：

1. seq gap（seq 空洞）；
2. sourceEventSeqs must reference earlier events（引用未重映射，1 个引用指向被折叠删除的事件）；
3. provider 400（压缩边界切断了 tool 往返，残留孤儿 tool/result，消息重建时产生未配对的 tool_calls）。

证据：未被任何工具修改过的原始备份本身就含 1,415 个 seq 空洞；67.5 万个引用中有 67.5 万个需要重映射。

建议修复：压缩后重编号 + 重映射引用 + 保证 tool 配对边界 + 写入时校验；并提供官方修复命令。

临时方案（已验证）：解压全部 zstd 帧 → 重编号 seq → 重映射所有引用 → 按原 checksum 参数重写 → 磁盘回读验证。两个会话（695,462 / 1,594,969 事件）均恢复且持续正常使用，消息内容零丢失。

---

与已有讨论的关联（补充）

GitHub Discussions 中已有两帖报告症状相似但根因不同的 bug：

• seq 序号重复导致对话加载失败 #1333（Firefly1007）：seq 147513–147516 重复 → 加载失败
• BUG: 同一 DSH_HOME 下多进程并发写同一会话日志，导致 seq 重复、整段历史无法加载 #1452（cow114514true）：同一 DSH_HOME 下多进程并发写同一会话 → seq 38422–38425 逐字节重复两次

二者的根因是跨进程并发写入（appendLines 使用无锁的 open(path, 'a')，O_APPEND 只保证单次 write 不撕裂，不保证 seq 不重叠；PersistenceCoordinator 的串行化只覆盖进程内）。

本报告与之不同：我们的会话全程只有单个进程写入；损坏形态是 seq 空洞（事件被压缩折叠删除后未重编号）而非重复，且伴随 sourceEventSeqs 悬空引用与孤儿 tool/result。这是 /compact 压缩路径自身的 bug，与并发写入无关。两者都值得维护者修复，但修复点不同（压缩事务 vs 跨进程锁）。