Orphaned `byMessageId` entries with emptied `activeBlockIds` stay visible forever

[ranxianglei]

来源: #368 (#368) 分析 "compress-call reasoning inflates the incompressible floor" 时发现

问题

filterCompressedRanges 中，当某条消息的 byMessageId 条目的 activeBlockIds 被清空（但条目本身仍存在）时，survive[i] 被置为 true，导致该消息永久可见，即使它本应被压缩 / 隐藏。

证据

• lib/messages/prune.ts:60-66（:62-63）：

  const pruneEntry = state.prune.byMessageId[messageId];
  survive[i] = !pruneEntry || pruneEntry.activeBlockIds.length === 0;

  即：无条目 → survive；或条目存在但 activeBlockIds 为空 → survive。
• 当 block 被 deactivate 但 byMessageId 条目未清理时，activeBlockIds 变空 → 消息变回可见。

影响

• 已压缩消息的内容（含 reasoning）重新出现在上下文里，形成额外的不可压缩残留（Protected-message exemption inflates the incompressible context floor: per-compression reasoning is never reclaimable (~83.5% of measured residual) #368 样本中 8 条消息 / ~28 KB）。
• 与"压缩后应隐藏"的预期不符。

建议修复

根因在 activeBlockIds 清空后 byMessageId 条目未同步删除 / 标记。需排查 block deactivate 路径（syncCompressionBlocks / GC）是否应清理 byMessageId 条目，或让 filterCompressedRanges 区分"从未压缩"与"已压缩但 block 已失效"两种情况。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Triage 完成 —— 已逐行核实所引代码,但结论与 issue 的预设有分歧:这个"可见"不是 filterCompressedRanges 的 bug,而是 decompress 的承重语义;issue 给的两个修复方案,一个无效、一个会破坏 decompress。详情如下。

1. 验证(对当前 master @ 6a8e531)

• 所引代码属实(API 形态与 issue 引用略有出入:byMessageId 是 Map,不是下标对象):lib/messages/prune.ts:60-66

  const pruneEntry = state.prune.messages.byMessageId.get(msg.info.id)
  if (!pruneEntry || pruneEntry.activeBlockIds.length === 0) {
      return true // survive → 可见
  }

• "条目存在、activeBlockIds 空、allBlockIds 非空"这个状态可达:syncCompressionBlocks 每次 message-transform 都重算(lib/messages/sync.ts:83-90):

  entry.activeBlockIds = allBlockIds.filter((id) => messagesState.activeBlockIds.has(id))

  条目 allBlockIds 里的 block 全部 inactive 时,activeBlockIds 变空 → 消息重新可见。

2. 层次分析:根因不在 filterCompressedRanges

我枚举了当前代码全部 5 个 block 失效点(block.active = false / deactivatedByUser*):

位置	路径	byMessageId 条目是否同步更新	消息应保持隐藏?
lib/compress/state.ts:207	新 block 消费旧 block	✅(移除旧 ID、加入新 ID;新 block 的 effectiveMessageIds = selection ∪ 被消费 block 的 effective,覆盖关系传递)	是 → 保持隐藏 ✓
lib/gc/merge.ts:146	GC merge(100% fallback)	✅(merge.ts:163-173)	是 → 保持隐藏 ✓
lib/compress/decompress-logic.ts:128	用户 decompress	❌ 故意不动	否 → 应重新可见(这正是 decompress 恢复消息的机制)
lib/messages/sync.ts:44	强制 deactivatedByUser(Deep) 失效	同 decompress	同 decompress
lib/messages/sync.ts:59	强制消费失效	同消费	同消费

结论:当前代码里"被消费/被 merge → 重新可见"不可能发生;带条目的消息重新可见只有两条路径:decompress(有意) 或 索引发散(entry ↔ block 不一致)。

关于 #368 样本(8 条 / 28 KB):审计明确这 8 条消息 "not in any block's effectiveMessageIds" —— 即没有任何 active block 覆盖它们。此时原始消息是该内容唯一存留记录(block 摘要不列它们,decompress 也恢复不出)→ 可见是数据正确的,隐藏才是数据丢失。

另外我逐个核对了所有 byMessageId 消费方:对"条目存在但 activeBlockIds 空"与"无条目"的处理完全一致(prune.ts:62、state/utils.ts:26、protected-content.ts:25/65/119、status.ts:150/276/311、pipeline.ts:219、decompress-logic.ts:112-116)。所以这 8 条消息上,孤儿条目本身无功能影响 —— 条目在不在,它们都可见。"不可压缩"来自另一机制:若消息含 compress/skill part,会被 filterProtectedToolMessages 从所有压缩选择中硬排除(Bug 39,protected-content.ts:188-234)—— 那是 #368/#370(stripProtectedReasoning)在处理的地板,不是孤儿条目造成的。

3. 方案评估:两个提议都有问题

1. "deactivate 时清理 byMessageId 条目" —— 无效:filterCompressedRanges 对"无条目"与"activeBlockIds 空"一视同仁(都可见),删条目不改变任何可见性;反而改变 byMessageId.has(id) 语义(decompress 出的消息会重新进入 recent-tail 保护列表、filterLastUserMessage 会选中不同的"最后一条 user 消息")——零收益、有语义风险。
2. "区分'从未压缩'与'已压缩但 block 失效',后者隐藏" —— 破坏 decompress:decompress 产生的状态恰好就是"条目存在 + activeBlockIds 空"(deactivateCompressionTarget 设计上不动条目)。隐藏这个状态 = decompress 不再恢复消息。

4. 真正值得修的(我的方案)

真实缺口:entry ↔ block 之间没有任何一致性校验。#368 样本的发散(条目引用了不列该消息的 block)只能来自旧版本状态(该会话 9.5 天跨多个 ACP 版本;条目语义在 #200 有过变化)或 DCP 迁移状态 —— 当前代码路径严格保持 entry 与 effectiveMessageIds 锁步更新(上面已验证,写入点仅 compress/state.ts、gc/merge.ts、sync.ts、load 四处)。

建议:在 syncCompressionBlocks(每轮已重写这些字段,无额外时机风险)加单向自愈:对每个 block 的 effectiveMessageIds 中每条消息,确保条目存在且 allBlockIds 含该 block ID(只增不删 → 不会把任何消息孤儿化,旧状态也不会因删引用而上下文爆炸)。效果:

• "active block 覆盖该消息但索引漏了"(唯一真正 bug 的状态)→ 消息重新隐藏(内容已在 active 摘要里,原消息可见纯属重复);
• decompress 状态(无 active block 覆盖)→ 不变;
• Protected-message exemption inflates the incompressible context floor: per-compression reasoning is never reclaimable (~83.5% of measured residual) #368 样本(无 block 覆盖)→ 不变(可见是数据正确的,见上)。

我按这个方案实现(分支 + devlog + 测试 + PR)。若你认为不值得做,本 issue 的结论即"filterCompressedRanges 非 bug、样本可见是数据正确、地板归因于 Bug 39 保护机制(#368/#370)",可直接关闭。