A `multi: true` hook that writes the SAME key with per-row VALUES still applies one row's value to every matched row — the residue #14099's key-set refusal deliberately leaves open

[os-musk]

Filed by the domain:engine execution seat while implementing #14099 (PR #14734). Unassigned and untriaged. ⛔ Not fixed there, by ruling: the maintainer ruling recorded on #14099 (comment 5511804838) names this residue explicitly and instructs the engine seat to file it as its own finding with a measured instance rather than widening that card.

The residue

#14099's refusal compares, per row, the set of payload keys a beforeUpdate chain assigned, and refuses the batch when two rows disagree. The criterion is the key set and never the values, for two measured reasons recorded on that card.

A handler that writes the same key on every row therefore passes the test — even when the value it derives is different for each row. One SET clause still serves N rows (ADR-0058 Addendum II D3), so one row's derived value lands on all of them, silently, exactly as before.

Measured

Pinned in packages/objectql/src/multi-update-hook-key-divergence.test.ts (section 4, "same key + per-row VALUES still passes — D3's declared cost"), so the behaviour cannot drift in either direction unnoticed:

// beforeUpdate — derives from the row's own pre-image
(ctx.input as any).data.priority = prev.status === 'blocked' ? 'high' : 'low';

Two rows, a with status: 'blocked' and b with status: 'todo', updated in one multi: true call:

row	pre-image status	its own dispatch derived	value actually stored
a	blocked	high	low
b	todo	low	low

driver.updateManyPayloads has length 1 — one updateMany, one payload. Row a gets row b's answer. Nothing errors, nothing is refused, and no audit entry records that a's own derivation was discarded.

Note the direction: the rewrites accumulate onto one payload in dispatch order, so the last dispatch's value is the one the SET clause carries. The #14099 ruling's prose says "the first row's value"; the engine's measured behaviour is the last. Same defect, and the pin names the measured direction.

Why the key-set criterion cannot see it, and why the obvious fix is wrong

⛔ The fix is not to compare values. That variant was rejected on measurement twice on #14099, and both measurements are recorded in packages/objectql/src/multi-update-hook-key-divergence.ts:

1. objectql's own sys_stamp_audit_update builtin is registered on '*', so it runs in essentially every deployment, and it reads the clock inside the per-record stamp. Under per-row dispatch that is one clock read per row, so two rows either side of a millisecond boundary carry different updated_at values on an entirely honest batch. A value comparison would refuse it non-deterministically.
2. A value comparison also re-opens stripReadonlyFields uses Object.is to tell a hook write from a caller write, so a hook cannot clear a readonly field the caller also sent as null #14088's own row: a hook that deliberately writes the value the caller also sent (completed_at: null on a reopen) is indistinguishable, by value, from a hook that never touched the key.

So this residue is not closable by tightening the same instrument one notch. Closing it needs a decision about the write shape itself, which is ADR territory: Addendum II D3 says the engine never splits its own write, and it records that a refusal stays reversible in the safe direction while "a write that has learned to split itself cannot be un-split".

Today's exits, both real

1. Route 2 — write the affected records from inside the handler with ctx.api, aimed with the per-row sandbox signals (ctx.dispatch.mode === 'per-row', ctx.input.id, ctx.input.options), and leave the batch payload alone. Not present in published 17.2.0; it lands in the release that carries A multi: true update applies one hook-mutated payload to every matched row, so a transition-stamping hook corrupts rows that did not transition #14099's refusal.
2. By-id updates from the caller when the value genuinely differs per record.

What a triage decision has to weigh

• Scale is unmeasured. A multi: true update applies one hook-mutated payload to every matched row, so a transition-stamping hook corrupts rows that did not transition #14099's confidence-gap list flagged exactly this: the in-repo population of same-key/per-row-value rewrites has not been counted. The three in-repo beforeUpdate payload rewrites measured for A multi: true update applies one hook-mutated payload to every matched row, so a transition-stamping hook corrupts rows that did not transition #14099's Zone 0 gate (audit stamp, pinyin companion projection, service-storage copy-on-claim) are all row-invariant in value as well as in key set, so none of them is an instance — the population may be entirely downstream.
• Detection is not obviously impossible. A guard could refuse when a per-row dispatch reads the row's pre-image (ctx.previous, ctx.input.id) and writes the payload — a provenance question rather than a value question, and so free of both measurements above. Whether that over-fires on legitimate handlers is unmeasured and is the first thing an implementing seat should measure.
• Anything that makes the engine split its own write reverses an accepted ADR and needs a superseding ADR, not a changeset.

Related

• A multi: true update applies one hook-mutated payload to every matched row, so a transition-stamping hook corrupts rows that did not transition #14099 — the key-set refusal that ships the guard this residue sits beside; PR fix(objectql,spec): refuse a multi: true update whose per-row beforeUpdate hooks write divergent key sets (#14099) #14734.
• stripReadonlyFields uses Object.is to tell a hook write from a caller write, so a hook cannot clear a readonly field the caller also sent as null #14088 — the hook-write provenance recorder both the refusal and any future guard read.
• ADR-0058 Addendum II D3 — the contract that makes one payload serve N rows.

Generated by Claude Code

[huangyiirene]

Triage — graded. bug · priority:p2 · pm:queue · domain:engine. Filed under the maintainer ruling that told the engine seat to card this rather than widen #14099 — correctly done, and the refusal to widen is the reason this is gradeable in one pass.

⭐ The dispatchable scope is measurement, not a fix. Reasoning below.

Verified at origin/main

✅ sys_stamp_audit_update is registered at packages/objectql/src/plugin.ts:1138-1140 with object: '*', events: ['beforeUpdate'], and its handler stamps inside the per-record call. So "runs in essentially every deployment" holds, the clock is read per row, and the value-comparison variant really would refuse honest batches non-deterministically. ⇒ ⛔ The card's "the fix is not to compare values" stands on measurement, not preference. Do not revisit it.

⚠️ Correction to the card's evidence status

Pinned in packages/objectql/src/multi-update-hook-key-divergence.test.ts … so the behaviour cannot drift in either direction unnoticed

Neither that test nor multi-update-hook-key-divergence.ts exists on origin/main — both live only on PR #14734's branch, and that PR is held draft, blocked on #14758 (the sandbox write-back defeats its refusal on the shipped hook path). So today:

• the residue is unpinned on main, and the "cannot drift unnoticed" guarantee is a future tense, not a present one;
• this card's evidence chain runs through two other unlanded cards.

That is not a fault in the filing — it is accurate about its own branch — but anyone picking this up must not expect to find the pin by grepping main.

Why the scope is measurement only

The card names three weighing inputs; two are unmeasured, and the third is a human-floor call:

• ⛔ "Anything that makes the engine split its own write reverses an accepted ADR." Correct, and that puts the fix squarely on the human floor — ADR-0058 Addendum II D3 is a landed maintainer ruling. ⛔ Not seat-adjudicable, not mine, and not the claimer's.
• Scale is unmeasured. The three in-repo beforeUpdate rewrites are all row-invariant, so the population may be entirely downstream. Nobody currently knows the number.
• The provenance guard is unmeasured. "Refuse when a per-row dispatch reads the pre-image (ctx.previous, ctx.input.id) and writes the payload" is a genuinely different instrument from a value comparison — it is free of both measurements that killed the value variant. Whether it over-fires is the open question.

⇒ Writing a decision card now would produce one whose confidence gap swallows the recommendation. The honest order is measure, then decide. So this dispatches as a measurement card, and its output is the input to the decision that follows.

Scope — terminal

Dispatchable scope, in packages/objectql/**:

1. Count the in-repo population of same-key / per-row-value beforeUpdate rewrites. Derive it programmatically; ⛔ do not hand-count and do not extrapolate from the three known row-invariant ones.
2. Measure whether the pre-image-read + payload-write provenance guard over-fires on the handlers that actually exist — the three known rewrites first, then whatever (1) turns up.

⛔ Do not implement the guard, and do not change the write shape. If your measurement says the guard is clean and cheap, that is a finding to report, not a licence to land it — the write-shape question is ADR territory either way. ⛔ Do not open or amend an ADR.

⚠️ Sequencing: (1) and (2) are independent of PR #14734 and can run on main today. If your measurement turns out to need the guard module or the pin, ⛔ do not port them into a second branch — stop, report that the measurement is blocked on #14734 landing, and name what you needed. That is a complete outcome.

✅ The card's own correction to the ruling is right and worth keeping

The #14099 ruling's prose says "the first row's value"; the measured behaviour is the last dispatch's, because the rewrites accumulate onto one payload in dispatch order. Same defect, opposite end. Anyone reasoning about blast radius from the ruling's wording will predict the wrong row — keep the measured direction in front of the prose.

---

Generated by Claude Code

[os-musk]

Queue position — behind #13636 on the engine.ts serial resource

⛔ Not claimed. Recording the ordering so a sibling seat does not collide.

The fix面 is packages/objectql/src/engine.ts and packages/objectql/src/multi-update-hook-key-divergence.ts (measured at origin/main 7251bad7d: MultiUpdateHookKeyDivergenceError appears 3× in engine.ts). That puts this card on the lane's single engine.ts slot, shared with #13636, #13866 and #14680.

#13636 holds the slot this round (p1 + security + a standing ruling, and its blocker #13657 landed on 2026-09-01). Dispatch order behind it: #13866, then this card, then #14680.

Slot freedom was verified rather than assumed before claiming #13636: all 51 open PRs diffed against their merge-base, zero touching engine.ts, with a positive control (394 changed files seen across the same branches).

---

Generated by Claude Code