[finding][objectql] lifecycle-service 还有两条 #4747 未覆盖的破坏性操作腿:abort 抬起后仍发 reclaimSpace(VACUUM)与 rotateShards(DROP 分片)—— 探针实测,当前不可达

[baozhoutao]

来自 #5966 / PR #6397 实施期的必答项探针(一次性探针已删,证据在该 PR 正文「顺带发现」一节),按 PD #10 记录,未认领。dev 已做三仓查重(reclaimSpace / rotateShards / teardown 关键词零命中),本单为唯一入口。

两条腿(均为「控制流已读到 aborted === true 之后仍发破坏性操作」,与 #5966 同形)

1. lifecycle-service.ts:616 driver.reclaimSpace() —— 对象循环之后的空间回收循环。abort 落在最后一个声明对象的 reap 内时,batchedReap 在 :1215 读位 break、对象循环自然结束(不经 :598 的对象间 return),控制流落到 :614,向正在关闭的 datasource 发 VACUUM 级操作。探针实测 reclaims === ['vacuum']。
2. lifecycle-service.ts:852 driver.rotateShards() —— 对象同时声明 ttl + storage.strategy: 'rotation' 时,ttl reap 读位 break 返回后,无判定地发出物理分片轮转(DROP 过期分片)。探针实测 drops === ['DROP shard']。仅声明 rotation(无 ttl)的一路属「无人读过位」的良性形态,不在此列。

为什么是 finding 而非 pm:queue

两条今天同样不可达:仓内无平台对象声明 storage.strategy: 'rotation'(仅测试与 spec fixture);reclaimSpace 一条需要 abort 恰落在最后对象的 reap 内。修法与 #5966/PR #6397 同款(判定合取项 + 同注释口径),成本低,但无现实触发面 —— 交发现分诊轮定级。

另::1134 无 find 引擎的兜底 DELETE 在 N 租户下的 N+1 形态与在册 #5756 同区域,已按 dev 判断并入其观察面,不单列。

Refs:#5966、PR #6397、#4747(纪律)、PR #5956(第一腿)、#5194。

[claude]

Findings triage — PROMOTE. finding → pm:queue; domain:engine-core applied (this card had no domain:* at all, so it was invisible to lane selection as well as to the queue).

Stale-premise check — both limbs verbatim on origin/main, at the paths as re-verified (the file is packages/objectql/src/lifecycle/lifecycle-service.ts, not .../services/...):

• :616 await driver.reclaimSpace!(); — inside for (const driver of reclaimable), reached straight after the object loop, with no abort read between the loop exit and the call.
• :852 const res = await driver.rotateShards(obj, this.now()); — guarded only by lc.storage?.strategy === 'rotation', driver capability and supportsRotation !== false. No abort conjunct.

The parent is finished, which is what makes this promotable rather than a wait: #5966 closed via PR #6397, merged 17:15:25Z — six minutes before this card was filed. So the fix shape is not a proposal, it is a landed pattern with a reviewed comment idiom to copy.

Why promote instead of hold, given both limbs are unreachable today. Reachability is the wrong axis here, because #4747 is a discipline the repo already adopted, not a bug report — "no destructive operation after the abort bit is up". Under an adopted invariant, a known-but-unreachable limb is not a dormant defect; it is an enforcement gap that survives every green run, and today's unreachability is an accident of the current corpus (storage.strategy: 'rotation' appears only in tests and spec fixtures; the reclaimSpace path needs abort to land inside the last declared object's reap). Neither guarantee is asserted anywhere, so nothing fails when they stop being true. The prior limbs (PR #5956, PR #6397) were fixed on exactly this reasoning; leaving 2 of N unfixed leaves the invariant partially enforced, which is the state that produces the next incident. There is no design question left to settle, and the probe evidence is concrete rather than argued: reclaims === ['vacuum'] and drops === ['DROP shard'] were both observed, not inferred.

Scope for the implementing seat, stated tightly: the two named call sites, the same predicate-conjunct + comment idiom as PR #6397, and the same test shape. Explicitly out of scope: the :1134 fallback DELETE N+1 (already folded into #5756), and the rotation-without-ttl path (the body correctly grades it benign — nobody read the bit there).

Dedup — the filing dev swept all three repos on reclaimSpace / rotateShards / teardown with zero hits, and this card is named as the single entry point. Re-checked against open cards in the lifecycle/objectql area at this round: nothing else claims these two limbs.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code