[观察,机制未确认] 对不存在的记录 id 走 action body 更新时,afterUpdate hook 的 condition 读 previous 报 400 HookConditionError,而非干净的 not-found

[baozhoutao]

来源:#5519(PR #5569)复现过程中的偶发观察,dev 按「不 sit on finding / 不 mis-attribute」原则完整记录原始证据但未立单;PM 以观察类立单保存证据,机制未确认,标题只陈述症状。

原始证据(#5519 的真机等价 harness,bootStack(showcaseStack, {automation:true}))

对不存在的 showcase_task id 走 action body 更新时,偶见一次:

400 HookConditionError
showcase_audit_task_completion (afterUpdate, condition 读 previous):
"previous is not bound for this operation — operation aborted"

dev 已排除的候选机制

HookConditionError 刻意绕过 onError/async 是 #4775 的既定裁决,并非缺陷——这条路径不是问题所在。

未确认的候选机制(立单原因)

「目标行不存在 → previous 未绑定 → 整个写被 400 中止,而非干净的 not-found」。dev 未能在隔离环境复现确认,且该机制紧邻 #5037 / #5038 与 ADR-0058 bulk-write 附录的既有裁决面——若按此归因立修复单,须先复现证实。

处置建议

派发时应作为「复现单」而非「修复单」:第一步在隔离 harness 里稳定复现并确认机制,第二步才谈修法(且修法可能落在既有裁决面内,需先读 #5037/#5038 与 ADR-0058 附录)。#5519 的 dev 表示可提供 harness 配方(见 PR #5569 报告的 out_of_scope_findings 段)。

关联:#5519、#4775、#5037、#5038、ADR-0058。

Filed unassigned,无标签,待分诊席判级分域。

[os-zhuang]

分诊:finding + domain:engine-core(域为暂定,按候选机制锚定)。

• 分类理由:机制未确认、dev 未能在隔离环境稳定复现 —— 观察类,按 ux(setup): 平台 SSO 后落地 Setup System Overview(全 0 审计仪表盘)— 新 builder 应落 /_console/home;Total Users 显示 0 #3083 同口径持有;晋级条件 = 稳定复现并确认机制,届时按正文的「复现单」纪律派发(第一步复现,第二步才谈修法)。
• 域锚定:候选机制落在 previous 绑定面 —— packages/objectql/src/plugin.ts:846(sys_fetch_previous_update)与 engine 的 update 分支,属 engine-core;若复现后归因改变,回分诊改标。
• 邻接提示:[rc 止血] 批量写上引用 previous 的 hook 条件:泛化失败换成点名批量限制的专门诊断 + ADR 补遗 #5037(批量限制专门诊断,已落地)、beforeUpdate hook 在 multi:true 批量更新上拿不到 ctx.previous —— sys_fetch_previous_update 依赖 input.id;引擎已为校验取 priorRows 却不喂 hook(17.0.0-rc.2) #5574(beforeUpdate multi 的 previous,本轮已转决策箱)同属 previous 绑定领地;复现时先读 批量写上 hook 的 previous:B1 已拍板(fail loud 无例外,并入 #4775);本条转为「批量写 hook 按行触发」设计卡孵化点 #4800 / [17.x] 批量写按行语义实现:hook 按行触发 + record-change trigger 按行绑定 previous/record(#4800/#4862 拍板 A) #5038 的按行契约裁决,避免与既有裁决面冲突。

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

---

Generated by Claude Code

[os-zhuang]

Findings triage round (triage seat Routine, 2026-08-07): hold — repro still owed, so the verdict stands. But the candidate mechanism now has a code-level anchor, and this turns out to sit inside an existing ruling's family rather than next to it.

Re-read against origin/main (1eb13a0). ⛔ Nothing below is a reproduction — the promotion condition ("stabilize the repro, confirm the mechanism, then discuss a fix") is unchanged and unmet. What changed is that the hypothesis is now falsifiable at a named line instead of being a guess.

1. Anchor drift — the line in the 08-05 grading has moved

sys_fetch_previous_update is at packages/objectql/src/plugin.ts:863, not :846. A dispatch that opens :846 lands ~17 lines short, in stampData. Corrected here so the eventual repro/fix issue does not inherit a stale pointer. (plugin.ts last changed at bbdbf287, 2026-08-06 14:23Z, #5998 — loadMetaFromDb, unrelated to this surface.)

2. The handler's guard shape is consistent with the observation

// plugin.ts:863
name: 'sys_fetch_previous_update',
object: '*', events: ['beforeUpdate'], priority: 5,
handler: async (hookCtx) => {
  if (hookCtx.input?.id && !hookCtx.previous) {
    const existing = await this.ql!.findOne(hookCtx.object, { where: { id: hookCtx.input.id } });

The guard tests that an id was supplied. It does not distinguish that from an id that matches no row: when findOne comes back empty there is nothing to bind, so previous stays unbound and any later condition reading it hits the CEL fault path. That is exactly the shape needed to produce the reported 400 rather than a clean not-found — which is what makes the hypothesis worth keeping, and equally what makes it still only a hypothesis. The open question is upstream of this handler and unanswered: why does a write against a non-existent id reach the afterUpdate stage at all, instead of failing not-found first? Until that is reproduced, blaming this handler would be mis-attribution — the handler may be behaving correctly on a path that should never have been entered.

3. The important find: #5038 already ruled this error wrong — on the sibling path

The message in the report comes from cel-fault.ts:136-137:

The <subject> reads 'previous', which is not bound for this operation — the scope holds 'record', plus 'previous' only when the record's prior state is in hand.

hook-condition-bulk-previous.test.ts carries a [#5038] block titled "the generic CEL fault is never the whole story on this path", which pins (:346-347) that on a batch dispatch the author must not be left holding either generic sentence:

expect(err.message).not.toMatch(/which this object does not declare/);
expect(err.message).not.toMatch(/which is not bound for this operation/);
expect(err.fault).toMatch(/Unknown variable: previous|No such key: previous/);   // raw fault still travels as a fact

So the principle — when previous is legitimately unavailable, a specific diagnosis is owed, not the generic unbound-root sentence — is already decided and shipped. It was implemented for the batch path. This observation is the same generic sentence surfacing on the single-id-not-found path, which #5038 did not cover.

That materially changes the shape of the eventual work, in the direction of it being smaller: if the repro confirms the path, the likely fix is extending an existing, ruled, tested specialization to one more case — not opening a new question about previous semantics. It also reinforces the body's original warning to read #5037/#5038/ADR-0058 first: not because a fix might collide with those rulings, but because it probably belongs to one.

4. Restart condition — kept, plus one cheap trigger that did not exist before

Unchanged primary: a stable, isolated reproduction confirming the mechanism. Then dispatch as a repro-first issue per the body.

Added, and this is the cheap one: #5574 is now pm:queue + target:v17 and unclaimed (it was in the decision box when this was graded on 08-05; it has since been promoted). Its whole subject is sys_fetch_previous_update failing to bind previous for multi:true — i.e. this exact handler. Whoever takes #5574 is already inside plugin.ts:863 with the previous-binding contract loaded. Ask them, as a must-answer in the dispatch prompt:

With input.id supplied but matching no row, does previous stay unbound and reach a condition evaluation? If so, does it produce the generic cel-fault.ts:136 sentence that #5038 forbids on the batch path?

A yes is the reproduction this issue has been waiting on, obtained for roughly zero marginal cost. ⛔ This is not a request to widen #5574's scope — the answer is a report line, not a fix; if it comes back yes, promote this issue on its own and let it inherit the #5038 specialization pattern.

⚠️ Note for whoever asks: #5574's fix will change this handler, so a negative answer measured after it lands does not retire this observation — it may only mean the path moved. Ask before or during, not after.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。 (Triage-seat Routine; not a claim. English per the language policy effective with #6029, merged 23:55:44Z.)

---

Generated by Claude Code

[claude]

Findings triage round (triage seat Routine, 2026-08-07 11:47Z fire): hold — the repro is still owed, so the verdict cannot move. One anchor correction, and one reading that shortens the eventual repro.

Re-read at origin/main 72847c5 (last grading was at 1eb13a0). ⛔ Nothing below is a reproduction; the promotion condition — stabilize the repro, confirm the mechanism, then discuss a fix — is unchanged and unmet.

1. Anchor drift, second correction in two rounds

sys_fetch_previous_update is now at packages/objectql/src/plugin.ts:899. The 08-05 grading said :846, last round corrected it to :863, and it has moved again — 1c625ca3a (2026-08-07 01:37Z, #5840, getDiagnosed / get() no longer answering a loader outage as "not declared") shifted it a further ~36 lines. That commit is unrelated to the previous-binding surface; it is line noise, not a premise change.

Worth saying plainly since this is the third anchor value on one issue: the line number is not the anchor — the hook name is. Whoever eventually takes this should locate it with git grep -n "sys_fetch_previous_update" rather than trusting any number written on this issue, including this one.

2. Guard shape unchanged, and the open question is still upstream of it

The handler still tests "an id was supplied" rather than "an id that matches a row", so an unmatched id leaves previous unbound and a later condition reading it takes the CEL fault path — consistent with the reported 400 HookConditionError. Still only consistent-with, not confirmed. The unanswered question remains one level up and is the one the repro has to answer first:

why does a write against a non-existent id reach the afterUpdate stage at all, instead of failing not-found first?

Until that is answered, attributing this to sys_fetch_previous_update would be mis-attribution — the handler may be behaving correctly on a path that should never have been entered. That framing is unchanged from last round and is restated because it is what keeps this out of the queue.

3. Why it is still held rather than closed

The hold is not free — it is an unconfirmed mechanism with a one-time observation behind it — but it is cheap and it has a named owner of the missing input: #5519's dev offered the harness recipe (PR #5569's out_of_scope_findings). The closing criterion would be "the repro was attempted and the symptom does not reproduce", and nobody has attempted it. ⛔ Closing an unreproduced 400 on an authorization-adjacent write path because nobody got round to the repro is the wrong direction; not proposing closure.

4. Restart condition (unchanged, restated)

Promote the moment the symptom is stably reproduced in an isolated harness, and dispatch it then as a repro issue, not a fix issue: step one confirms the mechanism, step two discusses a fix — and step two must start by reading #5037 / #5038 and the ADR-0058 bulk-write appendix, because the candidate landing site sits inside an existing ruling's family, not next to it.

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

---

Generated by Claude Code

[os-project-manager]

Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): hold confirmed. Mechanism unconfirmed by the original dev's own account (single occurrence, not reproduced in isolation) and it borders the #5037/#5038/ADR-0058 ruled surface — dispatching a fix card on an unconfirmed attribution is the known anti-pattern. Restart: a second sighting promotes this as a repro-first card, never straight to a fix.

---

Generated by Claude Code

[os-zhuang]

Findings triage round: HOLD (finding + domain:engine-core kept) — but this round found a real premise change, not just line drift: the handler every prior grading anchored on is gone, and the open question survived it by relocating.

Measured @ origin/main b88f5e8:

• sys_fetch_previous_update is RETIRED. packages/objectql/src/plugin.ts:931 is now a tombstone: "单 id update 把同一行前置状态读了 3 次(engine 前置行门 + sys_fetch_previous_update + plugin-audit captureBefore),且后两次不受任何按对象需求门约束 #5846 (a), delivered with beforeUpdate hook 在 multi:true 批量更新上拿不到 ctx.previous —— sys_fetch_previous_update 依赖 input.id;引擎已为校验取 priorRows 却不喂 hook(17.0.0-rc.2) #5574's engine half … Do not reintroduce it." Its guard is recorded as permanently false because update() now reads the prior row and binds hookContext.previous before dispatching beforeUpdate. Every anchor in the 08-05/08-07 gradings (:846 / :863 / :899) points at this tombstone now — as the 08-07 round already said, the hook name was the anchor, and the name is gone too.
• The question relocated rather than closed. The new binding is still conditional: engine.ts:7005-7010 — priorRecord = await driver.findOne(object, priorAst, preOpts); … if (priorRecord) hookContext.previous = …. A supplied id matching no row still leaves previous unbound on the rebuilt surface, so the reported shape (400 HookConditionError from a condition reading previous, instead of a clean not-found) remains structurally possible. Whether the write path exits not-found before any condition can run is exactly the unreproduced question from 08-05 — only its address moved.
• The 08-07 "cheap trigger" expired unused: beforeUpdate hook 在 multi:true 批量更新上拿不到 ctx.previous —— sys_fetch_previous_update 依赖 input.id;引擎已为校验取 priorRows 却不喂 hook(17.0.0-rc.2) #5574 landed (PR feat(objectql): dispatch before* hooks per matched row on a predicate bulk write (#5574, #5846) #6697) without the must-answer question being asked. That grading pre-recorded the consequence correctly: a post-landing negative would not have retired this observation anyway — the path moved.

Verdict: hold. Restart unchanged in substance, re-anchored in address: a stable isolated repro (or a second sighting) on the post-#5574/#5846 surface promotes this as a repro-first card; step two starts from #5037 / #5038 / ADR-0058 Addendum II, and now also the plugin.ts:931 tombstone. ⛔ Not proposing closure: the surface rebuild invalidates the old anchors, not the question.

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

---

Generated by Claude Code

[claude]

Findings round (periodic re-verification): HOLD maintained (finding + domain:engine-core unchanged). Re-checked @ origin/main 603cab8: the sys_fetch_previous_update tombstone survives with line drift (plugin.ts:931 → :959, with a second retirement tombstone now at :981); update() still binds hookContext.previous before beforeUpdate. The relocated open question (condition-visible prev on nonexistent-id action-body updates) is still unanswered on the card; restart conditions unfired.

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

---

Generated by Claude Code

[claude]

Findings round (quota re-verification): HOLD maintained (finding + domain:engine-core unchanged). Re-checked @ origin/main a76a3af: the sys_fetch_previous_update tombstones survive (plugin.ts:959 / :981); the relocated conditional binding is live — if (priorRecord) hookContext.previous = … at engine.ts:7822 and :8342 — so a supplied id matching no row still leaves previous unbound on the rebuilt surface. The unreproduced question (400 HookConditionError instead of clean not-found on nonexistent-id action-body updates) stands as filed; restart conditions unfired.

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

---

Generated by Claude Code

[claude]

Findings round (quota re-verification): HOLD maintained (finding + domain:engine-core unchanged). Re-checked @ origin/main c546c89: the sys_fetch_previous_update tombstone drifted one line to plugin.ts:958; the conditional binding if (priorRecord) hookContext.previous = … is live at engine.ts:7822 and :8342, so a supplied id matching no row still leaves previous unbound. The unreproduced 400-vs-not-found question stands as filed; restart unfired. Held.

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

---

Generated by Claude Code

[os-zhuang]

Findings triage (cadence re-check): HOLD — stays finding.

Premise re-verified on origin/main @ a3c0865: the fault machinery the symptom rode on is intact — the "reads 'X', which is not bound for this operation" diagnostic template lives at packages/objectql/src/cel-fault.ts:141, and the hook-condition fail-loud family (hook-condition-fail-loud.test.ts, hook-condition-bulk-previous.test.ts) still governs this path. Nothing has landed that would clean up the not-found-id ordering this card describes.

Why still held: the card is by its own terms a repro card — mechanism unconfirmed, one intermittent observation. It stays a finding until someone can dispatch it as "step 1: reproduce in an isolated harness" (the #5519 dev's harness recipe is the entry point); promoting it as a fix card would violate its own filing discipline.

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

---

Generated by Claude Code

[os-zhuang]

Findings triage round, 2026-08-11 (PM session, maintainer-directed: 「跑一轮集中定级」).

Graded: promote — as a REPRODUCTION card, per its own disposition note. Wrong error class (400 HookConditionError vs clean not-found) on a nonexistent id is worth settling, the engine-core queue has capacity, and the harness recipe is on file (PR #5569's report). Step 1 is stable reproduction; the fix only follows a confirmed mechanism, and must be read against #5037/#5038 + the ADR-0058 bulk-write appendix first.

finding → pm:queue (domain:engine-core).

---

Generated by Claude Code