Repository navigation
Exporting ONE session decodes EVERY persisted session (loadAll) — multi-long-session machines OOM the documented handoff workaround | 导出单个会话会解码存储里的全部会话（loadAll）——多长寿会话机器上官方交接手段 OOM 崩溃 #5062
Description
来源: #5026 (https://github.com/ranxianglei/billion-context/issues/5026)「dsh-native 长会话 turn 裸 TypeError」分析时发现
查重: 无（open+closed 检索 export/OOM/loadAll/heap 关键词，无同机制条目）。
症状
在持有多个长寿会话的机器上执行 bili export <session-id> --output handoff.md，node 直接崩溃：exit 134 (SIGABRT)，V8 堆耗尽于默认 ~2 GB 上限（现场来自 #5026：单会话 1184+ 请求、累计输入 ~1.385 亿 token；机器 8 GB 内存）。崩溃恰好打在「坏会话 → 导出交接 → 新会话」这条官方绕行路径上——最需要导出的会话，所在机器最导不出。
机制（master @ 9b6ec23 与 v0.1.208 均已核对）
exportSession（src/export.ts:354-357 @master / :330 @v0.1.208）第一步是：
const all = [...(await store.loadAll()).values()];即无论是否给了 selector，都把本机全部持久化会话水化进内存（逐个解码状态文件：blocks、保留原文、lastMessages 快照），然后才做选择。listSessions 早已有一条不水化的 SQL 快路径（#2960 R2.1，直接查 unified sessions 表），但 exportSession 的选择环节没有复用它。而选择本身（matchSession）只需要 id/label——summary 行里都有。
影响
- 可用性：[Bug][dsh-native] turn fails with bare TypeError (reading 'length') host-side before the request reaches the proxy - very long-lived session, intermittent #5026 这类「会话已不可用、靠导出交接救场」的场景，在存储足够大的机器上导出命令本身就 OOM；
- 成本：每次单会话导出都付全树解码的内存/CPU（O(存储总量) 而非 O(单会话)），handoff markdown 与 --jsonl 两条渲染路径共用同一函数头，全部命中；
- 潜在面：任何「解码后总字节 > 默认堆」的机器，按 id 导出任何会话都会崩。
建议修法（PR 随后）
- 用
store.unifiedSessionSummaries()（一条 SQL，与列表同源同权威）解析出选中的 id，再用既有store.loadSync(id, meta)原语只水化这一个会话（web 面板/fork 收养已在用的公开方法）； - 无 unified 索引（legacy 模式）或该行水化失败时，保留历史全量扫描路径（stderr 打降级提示）；
- 行为对齐声明：空库提示文案、no-match 错误、歧义前缀错误文本均不变；unified 模式下选择与列表共用同一索引权威（列表本就隐藏的文件幽灵行从此同样不可选——一致化，PR 内披露）；
- 回归测试：unified 存储放 N 个会话，selector 导出结果正确且 loadAll 不得被调用（原型 spy 钉住）；legacy 腿钉住回退方向（Test Blind Spot Retrospective: Reinforcing Negative Assertion Discipline, Tightening Fake Upstream Strictness, Thin Inst | 测试盲区复盘:补反向断言纪律、假上游严格化、薄安装冒烟、形态矩阵与生命周期覆盖 #3617 门禁纪律：正反双向）。
建议标签：bug / dsh / scope/storage / p2（有绕行的功能性缺陷：加大堆可能可过；非核心车道可用性停摆）
Activity
ranxianglei commentedon Oct 28, 2026
(ai: vllm-qwen/qwen3.8-27b)
查重: 不重复。 open+closed 按 export/OOM/loadAll/heap/handoff 多组关键词检索，无同机制条目。最接近的 #4750（bound ordinary session loads）是「单次加载体积上限/惰性字段」机制，与本题「选择环节水化全树」不同失败域；#4247/#4248 是交接文档内容缺失，症状不同。
标签: bug / dsh / scope/storage / p2（有绕行的功能性缺陷——加大堆可能可过，非核心车道可用性停摆；按 issue 建议打标）。
审核三步结论：
src/export.ts:357确认exportSession第一步即const all = [...(await store.loadAll()).values()]，与是否给了 selector 无关；而listSessions（同文件 :47）早已走unifiedSessionSummaries()一条 SQL 的快路径（Identity pipeline: key sessions by (agent, conversation id) in the unified store — decouple fold ledgers from protocol/host origin (#2938 / #2847 / #2671 defect-1) #2960 R2.1），选择环节却没复用。issue 描述的机制成立。loadSync(id, meta)只水化一个；legacy/水化失败保留全量扫描+stderr 提示；错误文案不变；回归测试正反双向钉住）。实现中另发现两个同机制面的点，一并处理并在 PR 披露：unifiedSessionSummaries()在 mysql 网络后端上返回[]而非其契约承诺的null（sync facade 的 miss 值），这会让listSessions在健康的 mysql+full 安装上显示空列表——顺手加一行守卫，独立标注 commit；开工计划：分支
2026-10-29_export-single-session-no-loadall，PR 引用 Closes #5062。回归测试：unified 存储放 N 个会话，按 id/label 导出正确且loadAll零调用（原型 spy 钉死）；legacy 腿钉住仍走 walk 的回退方向（#3617 门禁纪律正反双向）；空库文案、no-match、歧义前缀三处错误文本逐字对齐旧行为。fix(persist): summary facade misses on network backends instead of le…
ranxianglei commentedon Oct 29, 2026
[bot] (ai: vllm-qwen/qwen3.8-27b)
进度汇报：上一会话因一次长时间无响应的操作卡住 30 分钟被强制重启。已从中断现场恢复——工作树里留有一处中断造成的残缺代码（新函数返回了一个不存在的变量，属编译错误），先修复后继续。现已完成开发并开 PR。
PR #5084（Closes #5062）：#5084
两个提交：①主修复（src/export.ts + 回归测试）；②同机制附带发现（src/persist.ts 一行守卫）。
八问结论：
bili export <id>在导出任意一个会话之前会解码磁盘上全部已持久化会话；持有多个长会话的机器上直接 OOM 崩溃（exit 134），文档化的「坏会话导出 handoff」绕行方案（[Bug][dsh-native] turn fails with bare TypeError (reading 'length') host-side before the request reaches the proxy - very long-lived session, intermittent #5026）还没跑起来进程就死了。exportSession无条件先做全量目录扫描+全量解码，再拿选择器去匹配——选一个会话的代价被绑死在「解码所有会话」上。bili export完全不可用（崩溃），但不影响代理主链路、压缩与数据本身。[]而非契约承诺的null，健康 mysql+full 安装上会话列表显示为空——现按契约回退文件扫描。验证：新增回归测试 6/6 绿（双向钉死：full 模式下全量扫描可证明零调用；legacy 模式下可证明仍恰好走一次；含损坏信封不阻塞健康会话的 #5026 场景）；既有四个 export 相关套件 16/16 绿；typecheck 干净。全量回归以 CI 为准。
判定：可进入 review/merge（以 CI 绿为最终门禁）。