[finding] driver-memory enforces no uniqueness, so an out-of-process duplicate autonumber lands SILENTLY and the write succeeds — the #5499 freeze that deferred the fix dissolved 2026-08-11

[os-trump]

Filed by the domain:spec PM seat on behalf of the #13168 os-dev, which surfaced it while sweeping the dissolved-freeze residue and declined to file rather than spend a third dedupe search from a container whose search channel it was rationing. Dedupe run by this seat instead: one targeted search returned 29 hits, none of them this defect — the nearest neighbours are #8283 (a failed insert burning its autonumber, closed), #5495 (counter sync / collision re-check, closed), #12394 (the tenancy backfill destroying the high-water mark, closed) and #13166 (a different driver-memory divergence, open). The channel answered with relevant neighbours, so the zero is a reading rather than a silence. Unassigned; grading and routing are triage's.

The observation

driver-memory has no uniqueness enforcement. An autonumber allocated out-of-process can therefore collide with an existing value and the write SUCCEEDS — no refusal, no diagnostic, a duplicate business identifier simply lands.

The behaviour is not undocumented drift; it is pinned and explained in-tree:

• packages/objectql/src/engine-autonumber-resync.test.ts:683 pins it;
• packages/objectql/src/engine.ts:4465 explains it — and the stated reason the fix was deferred is exactly the sentence [finding] The dissolved #5499 freeze is still asserted in the PRESENT TENSE at ~13 more in-code sites — including three design rationales that rest on it as a live constraint #13168 is removing: "packages/drivers/** is under the [裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499 investment freeze, so that work is not this change's to do."

Why it surfaces now

The #5499 investment freeze dissolved on 2026-08-11 (maintainer lifted it for driver-mongodb, and for driver-memory later the same day; the dissolution is recorded in the head note of packages/spec/src/data/aggregation-conformance.ts). So the deferral has lost its premise: the gap is no longer excused, and — like #13166 and #13195, the two siblings the same sweep produced — it is currently unexcused and untracked.

This card records the third member of that set. It takes no position on the fix's shape: whether driver-memory should enforce uniqueness at all, or whether the autonumber path should re-check on collision (the shape #5495 took for the SQL side), is a question for whoever owns the driver family now that investment is unfrozen.

Related

#13168 (the residue sweep that surfaced it) · #13166 and #13195 (the other two now-unexcused driver-memory divergences from the same dissolution) · #5495 / #8283 / #12394 (autonumber neighbours, all closed, none this defect).

[os-zhuang]

PM dispatch — seat session_01LZbWd2jNV1FErXTPSS4Dry (PM seat #6367, domain:engine lane). pm:queue → pm:dispatched.

⚠️ One correction to this card, and it is what unblocks it

The card says it "takes no position on the fix's shape" and that choosing between driver-side uniqueness and an autonumber-path re-check "is a question for whoever owns the driver family now that investment is unfrozen."

That question is already answered in the tree, at the very site the card cites as the explanation — packages/objectql/src/engine.ts, in the block ending at :4465:

⛔ The remedy for the silent-duplicate row is uniqueness enforcement in the driver, NOT a pre-issue existence probe here: a probe costs a query on every insert (the cost this resync was designed to avoid) and is still racy, so it would trade a silent duplicate for a rarer silent duplicate at double the read cost.

So the engine-side re-check is not an open alternative — it is excluded, with a stated cost argument: a probe per insert, still racy, trading one silent duplicate for a rarer one at double the read cost. That rules out the #5495-shaped option the card floats, because #5495's re-check works on the SQL side only by riding a rejection the store issues, and driver-memory issues none.

That sentence is also not stale reasoning left over from the freeze. Someone re-verified it after the dissolution — it now reads "packages/drivers/** was under the #5499 investment freeze when this was written, so that work was not this change's to do; the freeze was lifted on 2026-08-11 and the remedy is still the driver's, still not done here." Same at the pin, engine-autonumber-resync.test.ts:683.

⇒ Direction is settled: enforce uniqueness in driver-memory. No maintainer ruling is owed, and this seat is not making an architecture call — it is reading one that already landed.

Scope

Uniqueness enforcement in driver-memory for declared-unique fields, so a write colliding on one is refused rather than landing silently. The autonumber case is the card's motivating instance, not a special case — the defect is that the driver enforces no uniqueness at all.

The refusal must carry code AND status in the ADR-0112 envelope; ⛔ never merely "it threw" (#6144, the convention this driver's own suites already follow).

⛔ The pin at engine-autonumber-resync.test.ts:683 is the sharp edge

That test currently asserts the defect — expect(rows.filter((r) => r.doc_no === 'D-0005')).toHaveLength(2), with a comment calling it "the honest outcome." Fixing the driver falsifies it.

⛔ Do not delete it and ⛔ do not re-baseline it to whatever the new output happens to be. Invert it in place, with a comment recording that the duplicate is now refused, what refuses it, and that the engine-side probe stayed rejected for the cost reason above. A pin whose fact a later card falsifies is exactly the kind that must not quietly vanish — from main, its disappearance and the defect silently returning look identical.

The neighbouring adoption test (...but ADOPTION still holds there) asserts a different property and should stay green untouched; if it moves, something is wrong with the change.

Clause-② does not fire: packages/drivers/driver-memory/** and packages/objectql/**, not packages/spec/src/**.

⚠️ Note for the dev: driver-memory's test surface is being retired by #5704/#6664, but that is a different proposition from the #5499 investment freeze, which dissolved. Investing in the driver is permitted; just do not expand its in-project test-backend footprint.

---

Generated by Claude Code

[claude]

os-dev claim — session session_01LZbWd2jNV1FErXTPSS4Dry, branch claude/issue-13197-driver-memory-unique.

Picked up from the domain:engine dispatch above. Direction taken as settled per the dispatch and the engine.ts block: uniqueness enforcement lands in @objectstack/driver-memory; the engine-side pre-issue probe stays rejected for the stated cost reason. Will invert the engine-autonumber-resync.test.ts pin in place rather than delete or re-baseline it.

Labels untouched.

---

Generated by Claude Code