AI Vault 扫描器延迟取消¶

扫描器子进程在其请求已经结算后仍保留了取消 ID。 当父进程发送取消时，其响应可能仍在传输中，因此这 不需要一个无效调用方。已完成的请求已经执行了 清理；没有任何剩余逻辑来删除新插入的 ID。

该修复仅在现有 pending 集合拥有该请求时允许取消。 该集合同时包含排队中和运行中的请求。它们的取消和清理 保持不变。没有协议或历史记录保留策略变更。

证明¶

在已安装依赖的仓库根目录中运行：

ORCA_BACKGROUND_LAUNCH=1 node --max-old-space-size=128 docs/audits/scanner-late-cancel/reproduce.mjs

该脚本加载已签出的生产入口，并通过仅在内存中移除三行 pending 成员资格守卫来派生修复前版本。它会检查该 守卫恰好出现一次；无需历史提交或 Git 访问。 Esbuild 在两个版本于独立 VM 上下文中运行之前剥离 TypeScript。仅 对导入的协作者进行桩替换：生产消息处理器、请求通道、 集合和清理均会运行。每个合成的首次提示请求完成后，其 对应的取消到达。

该脚本断言计数，并输出包含两个源 SHA-256 哈希以及 Node/平台/堆限制来源信息的 JSON。results.json 记录了一次在 Node v26.6.0 上、128 MiB old-space 限制下的运行。这测量的是保留的条目，而不是 RSS。

回归测试导入生产入口，并通过一个被允许的取消直接观察其现有 取消集合。它在成功和失败请求之后重复延迟取消，验证排队/运行中的取消，并 检查关闭清理。未添加生产诊断或仅测试用的导出。

ORCA_BACKGROUND_LAUNCH=1 node node_modules/vitest/vitest.mjs run --config config/vitest.config.ts src/main/ai-vault/session-scanner-service-cancellation.test.ts src/main/ai-vault/session-scanner-service-entry.test.ts src/main/ai-vault/session-scanner-service-client.test.ts

事件范围¶

相同的无条件插入存在于发布版本 v1.4.198 中。这会在扫描器子进程中保留数字 ID，而不是在 Electron 主进程中保留转录内容。这是一个具体的 小型泄漏；它无法解释 #19768 中报告的约 26 MB/s 主进程增长， 也无法确定 #19831 中作用域级峰值内存测量的原因。