finding(objectql): archive 的冷侧 keep prune 在 abort 位已抬起后仍发一次 DELETE —— 循环之后的那条腿没跟上 #4747

[baozhoutao]

观察类 finding,来自 #5755 / PR #5956 的实现。今天没有用户会撞到,记录在案由 PM 定级。

事实(origin/main + PR #5956)

PR #5956 给 archiveObject() 的批循环补上了 #4747 的 abort 检查(与 batchedReap 同款)。补完之后,archiveObject() 里循环之后还剩一条腿没有该检查 —— 冷侧 keep 保留期的 prune:

// (批循环在此 break —— 此时 this.abort.aborted 已确定为 true)

// Cold-side retention: `keep` bounds the archive itself.
if (archive.keep && typeof cold.deleteMany === 'function') {
  const keepCutoff = new Date(this.now() - parseLifecycleDuration(archive.keep)).toISOString();
  await cold.deleteMany(object, { where: { created_at: { $lt: keepCutoff } } });
}

于是 teardown 落在批循环中途时:循环按新检查停下,紧接着仍会向正在关闭的 cold datasource 发一次谓词 DELETE。

为什么值得单独记一条(而不是「单次 await,可接受」)

这与 #5194 之前「无 guard reap 是两个检查点之间的单个 await」的形态不同,差别在于代码是否已经知道答案:

• 那种形态里,abort 只可能在那个 await 进行中被抬起 —— 之后没有任何代码观察过这个位,继续执行不是「明知故犯」;
• 这里,控制流刚刚因为读到 aborted === true 而 break,然后仍然发了一次写。契约(每个 os migrate 子命令关停时，悬空引用巡检都会把 sys_metadata / sys_view_definition 报成 unreadableObjects（连接已关闭） #4747:「stop() 抬起 abort 位,sweep 在每个 leg boundary 检查」)在这一处是可判定的,却没判。

为什么现在不会有人撞到

三重叠加,比 #5755 还窄:

• archive 策略要求已配置 cold datasource(archive.to),未配置直接 skipped: 'archive-pending';
• 还要求显式声明 archive.keep(未声明则整条腿不执行);
• 目前仓内没有平台对象声明 archive,更没有声明 keep。

修法(一行,若 PM 认为该修)

把该腿并入同一个判定即可,例如 if (!this.abort.aborted && archive.keep && typeof cold.deleteMany === 'function'),或在其前加一行早退。语义上不存在取舍:cold prune 是纯保留期回收,推迟到下一轮 sweep 无任何副作用(它不像热删那样受「归档成功才热删」的配对约束)。

PR #5956 未顺手改:该 PR 的裁定范围是批循环那一行,且其测试 fixture 有意不声明 keep,以免断言一条本 PR 不治理的腿。

Found-during: #5755 / PR #5956

[claude]

发现分诊轮(#4949 纪律):晋级 pm:queue,摘 finding。域维持 domain:engine-core。按 step 0 的 restore-invariant 一类入队(不是新能力,是把一条已接受的契约在漏掉的那条腿上补齐)。

• 过时前提检查(origin/main 9e3709a)—— 成立,并补上正文未给的文件路径:落点是 packages/objectql/src/lifecycle/lifecycle-service.ts:1074–1077(正文只给了代码片段)。逐行实读:批循环内 :1061 有 if (this.abort.aborted) break;(带 每个 os migrate 子命令关停时，悬空引用巡检都会把 sys_metadata / sys_view_definition 报成 unreadableObjects（连接已关闭） #4747 注释,PR fix(objectql): Archiver 的批循环尊重 #4747 的 teardown abort 位 #5956 落地),循环出来后 :1074 的 if (archive.keep && typeof cold.deleteMany === 'function') 到 :1077 的 await cold.deleteMany(...) 确无任何 abort 判定。
• 来源 PR 已合并:PR fix(objectql): Archiver 的批循环尊重 #4747 的 teardown abort 位 #5956 已 MERGED ⇒ 正文描述的「补完之后仍剩一条腿」是 main 上的现状,不是对在飞 PR 的预测。
• 为什么晋级(正文的论证本轮核过,同意):关键不是「单次 await 可接受」,而是控制流刚刚因为读到 aborted === true 而 break,紧接着仍向正在关闭的 cold datasource 发一次谓词 DELETE —— 每个 os migrate 子命令关停时，悬空引用巡检都会把 sys_metadata / sys_view_definition 报成 unreadableObjects（连接已关闭） #4747 的契约(「stop() 抬起 abort 位,sweep 在每个 leg boundary 检查」)在这一处是可判定却没判,与 finding(objectql): LifecycleService 的无 guard reap 每次 sweep 发一条无上限 DELETE —— 首次给存量大表加 retention 时是一条长事务 #5194 之前那种「abort 只可能在 await 进行中被抬起」的形态本质不同。
• 零取舍 + 一行:cold prune 是纯保留期回收,推迟到下一轮 sweep 无副作用(不受「归档成功才热删」的配对约束)。修法即 if (!this.abort.aborted && archive.keep && …) 或其前加一行早退。派发时请顺带补一条钉住该腿的用例 —— PR fix(objectql): Archiver 的批循环尊重 #4747 的 teardown abort 位 #5956 的 fixture 有意不声明 keep,所以这条腿今天无断言覆盖。
• 今天不可达的三重叠加照旧成立(需配置 cold archive.to + 显式 archive.keep + 仓内当前无平台对象声明 archive)⇒ 优先级低,但入队条件与优先级是两件事。
• 查重:三仓无影子单;本轮 31 条 open PR 无在飞 PR 触 lifecycle-service.ts。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code