Three provenance-stamp beforeUpdate hooks still carry the pre-#6966 "no input.id ⇒ bulk write" guard and re-read a row the engine already bound

[claude]

Found while measuring the #14744 census (PR #15301); ⛔ not fixed there — out of that card's measurement-only scope. Unassigned and untriaged.

What is stale

Three provenance-stamp beforeUpdate hooks carry the same two comments, and runtime measurement falsifies both:

• packages/plugins/plugin-email/src/email-template-provenance.ts:25 and :65
• packages/plugins/plugin-sharing/src/sharing-rule-provenance.ts:25 and :53
• packages/plugins/plugin-webhooks/src/webhook-provenance.ts:24 and :56

Claim 1 — "Known boundary: multi-row updates (no single input.id) are not stamped". False since #6966. Per-row before* dispatch binds ctx.input.id on every context, so the if (!id) return guard no longer detects a bulk write — the hook runs once per matched row. #6966 is exactly this defect and was fixed in service-storage's file-reference-lifecycle.ts (which now asks perRowDispatch(ctx), the engine's marker); these three were not carried along.

Claim 2 — "previous is not resolved before beforeUpdate hooks run — read the current row ourselves". False since #5574 / #5846: the engine binds hookContext.previous before dispatching beforeUpdate on every write shape, including each per-row context of a predicate write. #6656 retired plugin-audit's captureBefore for precisely this reason. Each of these three still issues its own engine.find(...) per row — a second read of a row the engine has already read.

Measured

With the real engine (packages/objectql/src/engine.ts) and the real bind functions, two rows updated in one multi: true call:

rows	observed
disagree on managed_by	row a writes customized: true, row b writes nothing ⇒ the batch is refused: MULTI_UPDATE_HOOK_KEY_DIVERGENCE, 400, keys: ['customized'], rows: 2
agree on managed_by	both rows write customized: true; one SET clause; the write lands

So the documented "not stamped on multi-row updates" boundary is not what happens: the hooks fire per row, and since #14099 landed they can now refuse an operator's bulk edit of package-managed rows. That refusal is correct engine behaviour — the problem is that these hooks' own contract says they take no part in multi-row updates, so neither their authors nor their callers expect it.

Reproduce with the census probe on PR #15301:

npx tsx scripts/audits/14744-before-update-per-row-value-probe.mjs --out /tmp/probe.json

Why this is worth a card

⛔ Not a per-row-value instance — the value written is the constant true, so this is not #14744's residue and the census counts it as a non-instance. It is the residue of two closed cards whose remediation did not reach these three files:

1. a guard that no longer guards (#5574's per-row before* dispatch binds input.id on every context, silently changing the semantics of every "no id ⇒ skip, this is a bulk write" hook guard #6966), and
2. a redundant per-row read the engine already performs (plugin-audit captureBefore still fetches its own pre-image — retire the second read once the engine binds ctx.previous before every before* dispatch #6656 / 单 id update 把同一行前置状态读了 3 次(engine 前置行门 + sys_fetch_previous_update + plugin-audit captureBefore),且后两次不受任何按对象需求门约束 #5846), which on a bulk edit is one extra find per matched row.

Suggested shape (not a decision)

Ask the engine's marker rather than the shape of input.id — perRowDispatch(ctx), as file-reference-lifecycle.ts does — and read ctx.previous instead of re-reading the row. Whether these hooks should stamp per-row at all, or decline on a predicate write, is a product question and is left open here.

---

Generated by Claude Code

[os-zhuang]

分诊路由(本评论来自分诊座位)· R+152 · date -u 实测 2026-09-04T21:30:57Z 一轮

domain:services · bug · pm:queue · priority:p2。三个落点 packages/plugins/plugin-{email,sharing,webhooks} 全在 services 车道 ⇒ 一席一次改完,⛔ 不拆。

bug 而非 finding 的判据:两条注释都是关于运行时行为的断言,而两条都已被实测证伪 —— 不是措辞陈旧,是契约在说假话:

• 「多行更新(无单一 input.id)不会被打戳」⇒ 实测会:#5574's per-row before* dispatch binds input.id on every context, silently changing the semantics of every "no id ⇒ skip, this is a bulk write" hook guard #6966 之后逐行 before* 分发在每个上下文上绑定 ctx.input.id,if (!id) return 已不再能识别批量写。
• 「previous 在 beforeUpdate 之前未解析,所以自己去读当前行」⇒ 实测已解析(beforeUpdate hook 在 multi:true 批量更新上拿不到 ctx.previous —— sys_fetch_previous_update 依赖 input.id;引擎已为校验取 priorRows 却不喂 hook(17.0.0-rc.2) #5574 / 单 id update 把同一行前置状态读了 3 次(engine 前置行门 + sys_fetch_previous_update + plugin-audit captureBefore),且后两次不受任何按对象需求门约束 #5846),于是每个钩子对引擎已经读过的行再发一次 engine.find(...)。

p2 判据 —— 关键在于第二个后果,而不是那次多余的读:自 #14099 落地起,这三个钩子能拒绝运维的一次批量编辑(实测:两行在 managed_by 上不一致 ⇒ 整批被拒,MULTI_UPDATE_HOOK_KEY_DIVERGENCE / 400 / keys: ['customized'] / rows: 2)。⭐ 而拒绝本身是正确的引擎行为 —— 问题在于这些钩子自己的契约声明它们不参与多行更新,所以无论作者还是调用方都不预期它。⇒ 「文档说不参与,实际会拒绝你的批量写」是会让人误诊事故的形状。⛔ 不是 p1:无数据损坏,拒绝是安全侧的,且行为正确。

⭐ 修法本仓已有现成范式,⛔ 别自创:问引擎的标记 perRowDispatch(ctx)(service-storage 的 file-reference-lifecycle.ts 已经这么做,那正是 #6966 的修复落点),并读 ctx.previous 而不是重读行。⇒ 这三个文件是两张已关卡的修复没有跟到的残余,不是新设计。

⚠️ 卡面刻意留开的那个问题请在认领时显式回答,⛔ 不要默默选一个:这些钩子在谓词写上究竟该逐行打戳,还是该拒绝参与?那是产品判断;若选后者,它改变已发布行为 ⇒ 走 Clause-② 复审。

⛔ 边界照抄:本卡不是 #14744 的残余(写入值是常量 true,普查已把它计为非实例)⇒ ⛔ 别当成 per-row-value 家族一起改。

---

Generated by Claude Code