fix(driver-memory): bulkUpdate's touched-row set must agree with its own id resolution

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[zhuangjianguo]

Fixes#13911

The defect

InMemoryDriver.bulkUpdate used two lookups over the same ids, and they disagreed:

consttouchedIds=newSet(updates.map((u)=>u.id));// ids from the CALLERconstsettled=table.filter((r)=>!touchedIds.has(r.id));// STRICT Set.hasconstindex=table.findIndex((r)=>r.id==u.id);// LOOSE ==

IDataDriver.bulkUpdate declares id: string | number, and this driver resolves an id to
a row with a loose comparison — as update and delete always have — so naming a stored
1 as '1' finds the same row. But Set membership is always strict. For a mixed-type
id the row was therefore resolved and updated and left in settled carrying its
pre-image, so it entered the projected row set twice: once with the value it was
vacating, once with the value it was taking. exceptId does not help — it excludes only
the row currently being checked, never a sibling row of the same batch.

Net effect: a batch that merely hands a unique value from one row to another was
refused with a false UNIQUE_VIOLATION / 409.

The fix

Resolve every id to its table index first, then derive the touched set from the
resolved rows' own ids rather than from caller input:

constresolvedIndexes=updates.map((u)=>table.findIndex((r)=>r.id==u.id));consttouchedIds=newSet(resolvedIndexes.filter((index)=>index!==-1).map((index)=>table[index].id),);

Both lookups now read the same stored value and cannot drift apart — the property
updateMany gets for free by drawing its target ids from table rows.

⛔ Deliberately not fixed by tightening findIndex to ===. That would silently
narrow which ids resolve at all — a behaviour change far wider than this defect — and
update() one method up uses ==, so this door must keep matching its sibling's
resolution semantics. The bug is the disagreement; the resolution side is the side that
had to be preserved.

The main loop now reads each id's already-resolved index instead of resolving a second
time, which is what let the two lookups drift apart in the first place. Error precedence
is unchanged: the missing-id throw and the uniqueness refusal still fire at the same point
in batch order as before.

Correcting the record on the construction

The PR that introduced this (#13875, landed at 4642f4c64c) described its bulkUpdate as
generalizing updateMany's posture. It generalized the discipline — check every
pending row's post-image before writing any of them — but not updateMany's internal
consistency. That is the one way it diverged: updateMany's targetIds come from table
rows and its findIndex is strict ===, so both of its comparisons agree by
construction; bulkUpdate drew one side from caller input and the other from a loose
resolution. The landed changeset is left untouched (it is already merged); this note is
the correction.

bulkDelete — checked, not assumed

bulkDelete has no analogous gap, and the reason is structural rather than
coincidental: it performs exactly one id comparison (the resolving findIndex), and
everything downstream is keyed on that comparison's result — a table index — never on
caller input. There is no second lookup to disagree with the first.

That also makes its de-duplication type-proof: ['1', 1] against a stored 1 collapses to
one index. Had the set been keyed on caller ids instead, those would be two distinct
entries and the two splices would remove index 0 twice, taking a neighbouring row with it.
Both properties are now pinned by test rather than left to inspection.

exceptId semantics

assertNoUniqueViolation filters exceptIdstrictly (row.id === exceptId).
bulkUpdate already passed the storedtable[index].id there rather than the caller's
id, so self-exclusion was type-consistent and is unaffected by this fix — worth recording,
since passing caller input there would have been a second instance of the same class.

Tests

Added to memory-bulk-update-delete-atomicity.test.ts (the existing suite used string ids
throughout, which is why this passed 36/36):

• the regression — mixed id types, the vacate-and-take batch that must succeed;
• a positive control — the same batch shape with consistent id types, so the
  regression cannot pass vacuously;
• the stored id keeps its own type (a string id in the batch does not restamp it);
• a genuine collision is still refused with mixed id types (the fix does not turn the
  check off);
• bulkDelete with a mixed-type id, and the same row named twice in two id types.

Before the fix: 1 failed | 23 passed, the failure being exactly the mixed-type case with
Unique constraint violated on doc.doc_no: a record with the value "D-0001" already exists — a value the batch had just vacated. After: 24 passed.

Full driver-memory package suite: 38 files, 1018 tests, all passing.

Ablation on the committed fix: reverting the touched-set derivation to caller input,
proven on disk with anchored greps in both directions plus a changed blob hash, turns the
new test red and only that test; restored under trap with absolute paths, verified by an
empty git diff HEAD and a blob-hash match.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 8 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 275e755a7f3183e3711b85e5661aa771ed73b6c7 — the merge of head dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e into base 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 275e755a7f3183e3711b85e5661aa771ed73b6c7 && git checkout 275e755a7f3183e3711b85e5661aa771ed73b6c7
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e && git checkout -B drift-repro 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3 && git merge --no-ff dcbcb1e22ae69c400adc6d9c617eb0348c67bb7e
node scripts/docs-audit/affected-docs.mjs --json 4642f4c64c002f94f1d737bbb2a5fc94ae43ddf3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.