AI Vault 超大转录记录¶

本地/WSL 增量 JSONL 读取器会累积无换行符记录的每个数据块，然后在换行符或 EOF 处拼接并解码整条记录。其片段列表避免了平方级复制，但未限制内存。读取器和扫描器子进程的 384 MiB V8 旧空间设置都存在于 v1.4.198；该堆设置不会对外部缓冲区施加 384 MiB 的进程 RSS 上限。

该修复共享现有流式远程读取器的 10 MiB 记录限制，并在保留、拼接或解码超大记录之前检查本地字节数。它通过现有扫描问题路径拒绝该会话读取；不会静默丢弃记录，也不会在失败后推进已持久化的恢复点。因此，大于 10 MiB 的合法记录在该次扫描中不可用。包含许多较小记录的大文件仍可正常工作。这覆盖可恢复的 JSONL 路径，而非所有整文档/导入读取器。

复现¶

ORCA_BACKGROUND_LAUNCH=1 node --expose-gc docs/audits/transcript-record-retention/reproduce.mjs

该脚本在临时本地文件中写入一条 64 MiB 的合成记录，并打包实际读取器。仅将文件系统适配器替换为等效的原生 createReadStream 路径，外加一个字节计数器。基线在内存中移除三个新的预算检查。每个用例都在自己的 Node 进程中运行，并设置 --max-old-space-size=384；同时测试已终止和未终止的记录。临时文件会被删除。结果和捆绑包哈希 在 macOS 上使用 Node v26.6.0 捕获。

RSS 包含运行时开销；分配器行为会有差异。机制是无限制的记录组装及其副本，而非精确的采样值。普通的已终止记录之后可以被回收；这是峰值分配/OOM 风险，而不是每次读取后存在永久泄漏的证据。

验证：五个读取器/远程/缓存/WSL 套件中的 71 个测试通过，随后读取器和缓存恢复套件中的 10 个测试通过（其中 9 个重叠）。回归测试覆盖全部三种组装路径、精确字节边界、Unicode、大型多记录文件、迭代器清理，以及未变化的缓存恢复状态后成功修复。完整 typecheck、最终 node typecheck、lint 和变更代码质量检查均通过。测试使用了 ORCA_BACKGROUND_LAUNCH=1。

这是应用进程组内另一个可达的分配机制。#19831 并未确认存在超大转录记录。在报告的构建中，正常扫描运行在子进程中，因此该路径无法解释 #19768 中孤立的 main-PID 测量。未声称受影响主机归属。