A scalar `data.id` beside a DIFFERENT scalar `where.id` silently drops the `where.id` predicate — the one unhonoured-predicate shape #11009's refusal deliberately left standing

[os-zhuang]

Found while implementing #11009 (the unhonoured by-id predicate refusal). Filed separately and unassigned: acting on it would reverse a pinned #5748 verdict, which is a maintainer decision, not a rider on that card.

The shape

await engine.update(obj, { id: 'rec_1', title: 'x' }, { where: { id: 'rec_2' } });

resolveEngineUpdateDispatch rules by-id with expectId: 'rec_1' — the payload id outranks where (#5748, pinned in ENGINE_UPDATE_DISPATCH_CASES as 'a SCALAR data.id still wins over a scalar where.id'). The where.id = 'rec_2' predicate is then discarded by the by-id driver path exactly the way #11009's extra keys were: the caller wrote "update rec_1 where id = rec_2" — a condition that can never hold — and the write lands on rec_1 anyway, with no diagnostic.

Why #11009 did not cover it

#11009's refusal fires on where keys beyond id ("a by-id dispatch carrying predicate keys beyond id", per its triage route). Here the only where key IS id, so the refusal does not reach it — and making it reach would flip a case the shared case-set pins with an explicit expectId assertion, i.e. a partial rollback of #5748's ruling A. The #6435 block in engine.ts records the same boundary from the other side: widening beyond the ruled scope "is a separate decision, not a rider".

When the two ids are EQUAL the shape is redundant-but-honoured (the REST ingress folds the path id into the payload, so data.id === where.id is a normal spelling); only the UNEQUAL case is a silently-dropped declaration.

What a fix has to decide

1. Refuse a by-id dispatch whose where.id is a truthy scalar different from the bound payload id (same loud-refusal family as ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 / A compare-and-set where on a by-id update is silently inert — the extra predicate keys never reach the driver, and SqlHttpOutbox.redeliver's status guard is one of them #11009). Cheap, but changes a pinned verdict — needs a ruling.
2. Leave it, on the grounds that the payload id is the row address and a conflicting where.id is a caller bug too rare to arm. That keeps one silently-inert predicate shape in a family that has otherwise been made loud.

Refs: packages/metadata-core/src/engine-update-dispatch.ts (case 'a SCALAR data.id still wins over a scalar where.id'), #5748, #6435, #11009.

[os-zhuang]

Triage: 入决策箱(needs-user-decision + domain:engine,类型 Bug)。收紧它要部分回滚 #5748 的 pinned 裁决 A,只有维护者能翻已裁 pin。

一句话问题:调用方写「更新 rec_1,条件是 id = rec_2」——一个永远不可能成立的条件——平台不报错,直接把 rec_1 改了。这是「静默丢弃谓词」家族里被上一轮裁决刻意留下的最后一格。

选项(客户可感知代价):

• A — 收紧:by-id 派发遇到「where.id 是标量且 ≠ 载荷 id」时响亮拒绝(与 ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748/A compare-and-set where on a by-id update is silently inert — the extra predicate keys never reach the driver, and SqlHttpOutbox.redeliver's status guard is one of them #11009 同族的编写期错误)。代价:翻一条 pinned 用例(a SCALAR data.id still wins over a scalar where.id 的 expectId 断言反转为拒绝断言);两 id 相等的正常拼写(REST 把路径 id 折进载荷)不受影响。
• B — 维持:载荷 id 就是行地址,冲突的 where.id 视为调用方 bug、太罕见不设防。代价:全家族都改成响亮之后,唯一留下的静默格——AI 写出这个形状时,错误落库且零诊断。

业务直译:A = 转账单上「收款人」和「确认收款人」不一致就退回;B = 以第一格为准直接打款。

四轴:业务需求——形状罕见(实测由 #11009 实施时发现,非用户上报),拉动弱;长远合理——家族一致性:同类静默丢弃已全部改响亮,留一格特例是长期认知负担;防 AI 错——A 显著更优:矛盾输入被当场打回,而不是落库后无从追查;阶段聚焦——A 是一次窄改动+pin 反转,无扩散。

推荐 A,回退 B(裁 B 则在派发用例注释里写明「此格 deliberately 静默」并引用本裁决,让下一个实施者不再重开)。回一个字母即可。

裁后执行:A ⇒ engine 席派发,pin 反转遵循「被打断行为的 pin 反转为拒绝 pin,不是删除」纪律,拒收用例带 code+status 双断言;B ⇒ 关卡并在 ENGINE_UPDATE_DISPATCH_CASES 上补裁决注释(一行,引本卡)。

[facets-block]

• 业务需求:弱指 A —— 形状罕见、无用户上报,但撞上即错误落库
• 长远合理:指向 A —— 家族一致性:静默丢弃已全部改响亮,不留特例格
• 防 AI 错:指向 A —— 矛盾输入当场打回,优于落库后零诊断
• 阶段聚焦:指向 A —— 窄改动 + pin 反转,无扩散
  推荐:A(unequal 标量 where.id 响亮拒绝;翻 ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 pin 需你点头)· 置信缺口:两 id 不等形状的现网出现频率无读数;REST 之外的 ingress 是否依赖「payload 优先」未普查

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded (2026-08-23, live PM chat, verbatim: 「其他同意你的意见」— adopting this card's recommendation A): refuse a by-id dispatch whose where.id is a truthy scalar different from the bound payload id — same loud-refusal family as #5748/#11009. This deliberately reverses the #5748-pinned case 'a SCALAR data.id still wins over a scalar where.id' for the UNEQUAL shape only; the equal-ids spelling (REST folds path id into payload) stays honored.

State: needs-user-decision → pm:queue (same stroke). Dispatch constraints: pin-reversal discipline — the interrupted behavior's pin flips to a refusal pin, never deleted; refusal case carries code+status assertions; implementer surveys non-REST ingresses for payload-priority reliance (the recorded confidence gap) and reports readings in the PR — a measured contrary fact forks back here, no silent re-ruling.

---

Generated by Claude Code