exact-id membership vs block.effectiveMessageIds: remaining same-class sites (latent until sub-id projections ship)

[ranxianglei]

来源: #231 分析 sub-id 覆盖时发现

#231 (fixed in PR #233) corrected prune.ts and sync.ts, which compared block.effectiveMessageIds against current-view message ids with exact string membership. The same class of check remains at these sites (verified line numbers on master @ 04bd5ed):

Site	Check	Impact if projection forms diverge
src/recommend.ts:53	block.effectiveMessageIds.includes(message.id)	isSyntheticOrPruned misses → bad compression recommendations
src/decompress.ts:21	block.effectiveMessageIds.some((id) => messageIds.has(id))	block not recognized as covering the view → decompress no-ops
src/decompress.ts:105	b.effectiveMessageIds.includes(message.id)	block lookup by message fails
src/compress.ts:155	block.effectiveMessageIds.includes(rawId)	false "dangling ref" reports
src/compress.ts:1044	overlap detection: coverage set built from effectiveMessageIds, membership tested against message ids	false overlap → legitimate compressions blocked
src/boundaries.ts:259	inherited.has(id) (block owned ids vs another block's inherited content ids)	inheritance detection breaks if the two blocks recorded different forms (e.g. after a mid-session projection change)
src/report.ts:75,93	coveredIds set from effectiveMessageIds, coveredIds.has(message.id)	status report only (no behavior)

Latency: the kernel itself only emits plain base ids (h_<sha256>, _${N} cluster suffix — src/wire/message-id.ts), so all of these are latent today. They bite the moment an adapter projects sub-ids (base#callId, base#r0, …) or the projection form changes between turns — the same trigger as #231.

Suggested fix: reuse the baseIdOf / base-set normalization introduced in PR #233 at each site. Not done in #233 to keep that PR minimal and focused on the leak path (prune + sync, which is what actually resurrected messages).

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 已完成，PR: #235

审核结论（审核先于实现）

1. 复现/查证:逐一核对了表中 7 处 site 在 master @ 04bd5ed 上的代码,全部与 issue 描述一致——都是 block.effectiveMessageIds 与当前视图/引用表 id 的精确字符串成员判断。触发条件与 prune: isCovered misses base-id coverage when block effective ids use sub-id forms (base#suffix) #231 相同:adapter 投影出 sub-id(base#r0/base#call1)或投影形式跨 turn 变化时,这些判断全部静默失效。
2. 层次判断:issue 定位准确——这是 prune: isCovered misses base-id coverage when block effective ids use sub-id forms (base#suffix) #231 的同根因剩余面(exact-id membership),不是新类。fix: base-id coverage for sub-id projections in prune + sync (#231) #233 只修了实际复活消息的泄漏路径(prune + sync),其余 site 按"保持 PR 最小"原则留作跟进,即本 issue。
3. 方案评估:采纳 issue 建议的 baseIdOf/base-set 归一化,与 fix: base-id coverage for sub-id projections in prune + sync (#231) #233 模式完全一致;coverage 按 original message(base)判定,两侧都归一化,因此 block 形式与 view 形式任意组合都命中;不是前缀匹配(h_abcde 不会被 h_abc 覆盖,有测试守护)。

实现范围:表中 7 处全部修复,另在核实中发现同类的 3 处一并修复(已在 PR 中单独列出):

• src/decompress.ts collectBlockContent(target + nested-fold 两处集合)——prune: isCovered misses base-id coverage when block effective ids use sub-id forms (base#suffix) #231 triage 里已标记过,不在表中;
• src/boundaries.ts message-ref 查找的 base fallback(引用表可能持有旧投影形式);
• src/boundaries.ts visibleBlockAnchor/blockVisibleInRange/earliestIndexOfIds(block 形式 vs 视图索引表;导出函数加可选尾部参数,API 向后兼容)。

仅报告未修:src/wire/compress-detect.ts:180 boundaryRawCore 也是同类判断,但在 wire 子路径(replay guard,#91 谱系),有自己的测试套件,为保持本 PR 聚焦未动。要折进来还是另开 issue,你拍板。

测试:新增 tests/subid-membership.test.ts 19 个回归测试,覆盖每个修复点、双向投影(base block/sub-id view 与反向)+ 前缀安全对照。已对 pre-fix 代码验证:17/19 失败(2 个通过的是前缀对照,两态下都应通过)。全量 651/651 通过,typecheck 干净,build 成功。

PR 说明:stacked on #233(分支含其 commit 的 cherry-pick,baseIdOf 依赖它)。先合 #233 或先合本 PR 都可以,另一个会自动 resolve。另:master 的 package-lock.json 落后 package.json 一个版本(0.0.58 vs 0.0.59,release commit 只 bump package.json 所致),已还原本地重写以保持 PR 聚焦,需要的话可另做 housekeeping。