delete() 的按对象前置行门在任何 kernel 托管引擎上恒真 —— ObjectQLPlugin 自带的 sys_fetch_previous_delete 以 object: '*' 注册在 beforeDelete

[baozhoutao]

发现于 #5860 的实施核对(PD #10 范围外发现,未在任何 PR 内修改)。

事实(origin/main)

packages/objectql/src/engine.ts:6112,delete() 的前置行(pre-image)需求门:

const wantsPreImage =
  this.hasHooksFor('beforeDelete', object) ||
  this.hasHooksFor('afterDelete', object) ||
  this.getSummaryDescriptors(object).length > 0;

packages/objectql/src/plugin.ts:871,ObjectQLPlugin 自己注册的内建 hook:

{ name: 'sys_fetch_previous_delete', object: '*', events: ['beforeDelete'], priority: 5, ... }

hasHooksFor 把 '*' 正确地当作命中每个对象,于是只要 ObjectQLPlugin 在(即任何 kernel 托管的引擎),wantsPreImage 的第一项恒真、后两项永不被求值 —— 这个门在真实部署里从来没有判过假。

实测(计数驱动,只注册这一条内建形状,完全不装 plugin-audit):对一个既无 delete hook、也无 roll-up 汇总的对象做单 id delete(),driver.findOne 增量 = 1。

为什么这不是 #5272 的重复

#5272 把 delete 侧的前置读提前到派发 beforeDelete 之前并绑定 previous,让 before/after 两个阶段共用一次读 —— 那次改动是对的,而且正因如此,内建 sys_fetch_previous_delete 的 if (!hookCtx.previous) 现在恒为假,它自己不再多读一次。

剩下的是另一个问题:那条 object: '*' 的注册仍然留在注册表里,而需求门是按注册面算的,于是门本身失去了判假的能力。换句话说,内建 hook 的存在理由(「引擎不填 previous」)在 delete 侧已经不成立,但它的注册还在,并且它现在唯一可观察的效果,就是让按对象门恒真。

与 #5860 / #5928 的关系

• plugin-audit 的 5 个 hook 全部无 object 注册 ⇒ 引擎「按对象」需求门(#5284 单 id / #5038 批量)在 audit 启用时恒真 #5860(update 侧)的门只看 afterUpdate,而两条内建 '*' 注册(sys_stamp_audit_update、sys_fetch_previous_update)都在 before 事件上 —— 所以 update 侧的门确实是被 plugin-audit 的全局 afterUpdate 顶住的,plugin-audit 的 5 个 hook 全部无 object 注册 ⇒ 引擎「按对象」需求门(#5284 单 id / #5038 批量)在 audit 启用时恒真 #5860 的验收判据在 update 侧成立。
• delete 侧不是:即使 plugin-audit 把 captureBefore 的 beforeDelete 注册收窄,本单这条内建注册仍让门恒真。两者独立,需要分别解。
• 表达能力的缺口(注册面只有允许列表)记在 hook 注册契约只能表达「命中这些对象」,无法表达「全局但排除这些对象」—— #5860 因此在 plugin-audit 内无法落地 #5928。

可选方向(交分诊定,本单不预设)

1. 既然 单记录 delete 从不绑定 hookContext.previous —— 契约声明「for update/delete」,引擎只在 update 分支赋值;#5038 之后批量 delete 反而比单记录 delete 更完整 #5272 之后 delete 侧的 previous 已由引擎自己绑定,sys_fetch_previous_delete 是否可以直接退休?需要先确认引擎的绑定覆盖了哪些分支(单 id 有;谓词 delete 走另一条路径)。
2. 或者让内建 hook 不参与需求门的计算 —— 例如按 packageId: 'sys:audit' 在 hasHooksFor 中排除,或把它改成一个不经注册表的引擎内联步骤。⚠️ 前者会让「门」和「派发」的语义分叉,[17.x] 批量写按行语义实现:hook 按行触发 + record-change trigger 按行绑定 previous/record(#4800/#4862 拍板 A) #5038 的注释专门警告过这个方向,若走这条要显式论证。

Refs:#5860、#5928、#5272、#5284、#5038、#5846

[claude]

分诊:pm:queue(可派发)+ 维持 domain:engine-core。

⚠️ 与 #5979 / #5980 同属本轮扫到的**「半分诊」态**:有 domain:engine-core 但无 pm-state 标签 ⇒ 此前对所有队列视图不可见。

过时前提检查(origin/main 9e3709a)—— 两处锚点实读,均成立(行号有小幅漂移,已更新)

• wantsPreImage 三元判据在 packages/objectql/src/engine.ts:**6125**(正文记 :6112,已前移;:6145 / :6160 两处消费点同在);
• sys_fetch_previous_delete 的 object: '*' / events: ['beforeDelete'] 注册在 packages/objectql/src/plugin.ts:**888**(正文记 :871)。

⇒ 「只要 ObjectQLPlugin 在,wantsPreImage 第一项恒真、后两项永不求值」这个事实面成立。正文的计数实测(driver.findOne 增量 = 1)是可复现判据。

为什么入队而不是 finding:落点已钉死到两个文件的具体行,且有计数驱动的复现;后果是每一次 kernel 托管引擎上的 delete() 都多一次 findOne(对无 hook、无 roll-up 的对象也照读),即今天在跑的真实开销,不是休眠声明。两个候选方向都落在 packages/objectql 内部,不改任何对外契约 ⇒ 属车道内技术选型,⛔ 不进决策箱。

方向选择交 dev,但带一条硬约束(派发令请原样传下去):

• 方向 1(退休 sys_fetch_previous_delete)需先实测 单记录 delete 从不绑定 hookContext.previous —— 契约声明「for update/delete」,引擎只在 update 分支赋值;#5038 之后批量 delete 反而比单记录 delete 更完整 #5272 之后引擎自绑 previous 的分支覆盖面 —— 正文已点名单 id 有、谓词 delete 走另一条路径,这一步是前置取证不是可选项;
• 方向 2(按 packageId 在 hasHooksFor 里排除内建)⚠️ 会让「门」与「派发」的语义分叉,[17.x] 批量写按行语义实现:hook 按行触发 + record-change trigger 按行绑定 previous/record(#4800/#4862 拍板 A) #5038 的注释专门警告过这个方向 ⇒ 若选它,必须在 PR 正文显式论证为何此处可接受。

⛔ 一条容易被误读的依赖关系,先澄清:本单不继承 #5860 的 pm:blocked。#5860(update 侧)卡在 #5928(hook 注册契约无法表达「全局但排除」),而本单两个方向都是引擎内部改动、不需要 #5928 的表达力;正文亦已写明「两者独立,需要分别解」。⇒ 本单可独立派发,不加 Blocked-by:。

域锚定:落点 packages/objectql/src/{engine,plugin}.ts ⇒ domain:engine-core。

串行约束(硬,三条):

1. 在飞 PR fix(objectql): 新建父行时把 count/sum 型 summary 汇总初始化为 0 (#5749) #6013(Field.summary 的 count 汇总：从未有过子记录的父行停在 NULL，删光子记录才变 0 —— 同一个「零」两种值，筛选 = 0 静默漏行 #5749,ready)触 engine.ts ⇒ 排其后;
2. 在飞 PR fix(metadata,metadata-protocol,objectql): getDiagnosed —— get() 不再把 loader outage 答成「这一项没声明」 (#5840) #6051(draft)触 plugin.ts ⇒ 排其后;
3. 本轮同批晋级的 ObjectQL seedAutonumber 把读故障答成 return 0 —— 对已有 N 行的表重新从 1 发号,自增号与既有行相撞且零日志(#4825 同族,活体) #5979 同落 engine.ts ⇒ 两单 ⛔ 不得同轮派发。

查重:三仓 open issue / PR 各搜一遍 —— #5860(update 侧,pm:blocked)、#5928(注册契约表达力,pm:queue/domain:spec)、#5272 / #5284 / #5038 均为关联而非重复,各自入口不同;objectui / cloud 无影子单。

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

---

Generated by Claude Code