fix(driver-sql): re-seed a stale autonumber counter instead of burning a number per failed create (#5495) (#6932)

* fix(driver-sql): re-seed a stale autonumber counter instead of burning a number per failed create (#5495)

The counter bootstraps from the data-table MAX exactly once, in
`getNextSequenceValue`'s `if (!existing)` branch; afterwards the data table is
never consulted again. Any row landing by a path that bypasses
`fillAutoNumberFields` — an `isSystem` seed replay, a `preserveAudit` import,
or direct SQL — never raises the sequence, so once it sits below MAX it is
permanently behind and every create collides, burns a number and fails the
request until it has ground past the seeded range one 409 at a time.

Measured on main @ 86e6f6c with the counter seeded at 10 and rows 11-39 landed
by a bypass path: 29 caller-visible 409s before a create succeeded at
CASE-00040 on attempt 30. Now: CASE-00040 on the caller's first attempt.

`create()` re-seeds from MAX and retries (bounded) only when it can prove the
collision was that counter's. The proof cannot be the conflicting column:
`uniqueViolationColumn()` refuses composites, and ADR-0120 D3 makes the
tenanted index an expression composite on which SQLite names only the index —
so on this path the column is never determinable. All three of that export's
states are handled explicitly; the indeterminate one is decided from the data
(does the generated value already exist in this tenant partition?), never by a
hand-written dialect word-list.

Retry is confined to the no-caller-transaction case: inside a caller's
transaction the sequence UPDATE rolls back with the INSERT, so nothing is
burned, and on Postgres the transaction is aborted anyway.

The "gaps are tolerated by design" docstring is reconciled with the change
rather than left to contradict it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XLbsWE5G58ybd1Leq6bNg

* test(driver-sql): pin the three-state collision routing on Postgres and MySQL shapes (#5495)

The SQLite tests cover the path end to end, but SQLite is the one dialect
where the decision is easy. Postgres names a column in its DETAIL line
(state 1/2) or a composite (state 3); MySQL names only an index and so can
only ever reach state 3 — which means on MySQL the data probe is not a
fallback, it is the whole mechanism.

This package's unit suite boots SQLite only, so the shapes are injected
rather than driven through live servers — same method and same reason as
sql-driver-unique-violation-predicate.test.ts. The state-2 case asserts the
part that matters most: a named column that is not ours ends the matter
WITHOUT probing, even when the probe would have said yes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XLbsWE5G58ybd1Leq6bNg

---------

Co-authored-by: os-dev <steve@objectstack.ai>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: 3 people

.changeset/autonumber-sequence-resync-on-collision.md

@@ -0,0 +1,73 @@
+---
+"@objectstack/driver-sql": patch
+---
+
+fix(driver-sql): re-seed a stale autonumber counter instead of burning a number per failed create (#5495)
+
+`getNextSequenceValue` bootstraps a counter from the data-table `MAX` exactly
+once, in its `if (!existing)` branch; after that the data table is never
+consulted again. Any row landing by a path that bypasses `fillAutoNumberFields`
+— an `isSystem` seed replay, a `preserveAudit` historical import (both
+strip-exempt under #5503 and keeping their explicit numbers), or direct SQL —
+therefore never raises the sequence, and once the counter sits below `MAX` it is
+permanently behind. Every subsequent create collided, burned a number and failed
+the request, until the counter had ground past the seeded range one 409 at a
+time. That is the "one-time storm per database" the filing reported from
+HotCRM's 17.0 GA sweep: 25 consecutive `409 UNIQUE_VIOLATION`s with the
+attempted number climbing by one per failure.
+
+Measured on `main` @ `86e6f6c`, counter seeded at 10 with rows 11–39 landed by a
+bypass path: **29 caller-visible 409s before a create succeeded** at
+`CASE-00040` on attempt 30. After this change the same fixture serves
+`CASE-00040` on the caller's **first** attempt, and `last_value` reaches 40 by
+one re-seed rather than 29 burns.
+
+`create()` now re-seeds the counter from the data-table `MAX` and retries
+(bounded, 3 attempts) — but only when it can *prove* the collision was that
+counter's.
+
+**Why the proof is not the conflicting column.** The obvious predicate ("retry
+when the conflicting column is this autonumber field") needs
+`uniqueViolationColumn()` (#6544) to name a column, and on a tenanted autonumber
+it never does — for two independent reasons, both measured and both pinned by
+tests. The filing's own message is a composite
+(`UNIQUE constraint failed: crm_case.organization_id, crm_case.case_number`),
+which that export refuses by contract; and what this repo builds today is
+narrower still — ADR-0120 D3 makes the index
+`(COALESCE(organization_id,'__global__'), field)`, an *expression* index, on
+which SQLite reports `UNIQUE constraint failed: index 'uniq_…'` and names no
+column at all. The "column not determinable" limb is not an edge case on this
+path; it is the only limb that ever runs there.
+
+All three of `uniqueViolationColumn()`'s states are handled explicitly, because
+collapsing any two of them silently is how a real 409 gets eaten:
+
+1. a column is named and it is one this driver generated → re-seed and retry;
+2. a column is named and it is not → the duplicate is on a value the **caller**
+   supplied, so the original error is rethrown untouched;
+3. no column is determinable → decided from the **data**, not the message: if
+   the value this driver just generated is already present in the same tenant
+   partition the counter covers, the collision was the counter's. If it is not,
+   the error is rethrown. One indexed lookup, on the failure path only — the
+   happy path is unchanged.
+
+No fifth dialect word-list: the judgement is `isUniqueViolationError` +
+`uniqueViolationColumn` from `@objectstack/types`, per Prime Directive #12 and
+the #5841 precedent. The re-seed's `MAX` scan is deliberately not wrapped in a
+`catch`, so a read failure propagates instead of being folded into `0` or a
+stale value (#6114's rule, #5979's family).
+
+Retrying is confined to the no-caller-transaction case. Inside a caller's
+transaction the sequence `UPDATE` shares that transaction and rolls back with
+the refused `INSERT`, so no number is burned (measured), and on Postgres a
+constraint failure aborts the transaction outright — the caller owns that retry.
+
+The `getNextSequenceValue` docstring is reconciled rather than left to
+contradict the code: a rolled-back insert burning a number is still by design,
+and that sentence used to read as though it also covered a *persistently
+failing* insert, which was the defect.
+
+Inherited by `TursoDriver` (local/replica) and `SqliteWasmDriver`, each pinned
+by its own test rather than assumed from the base class (#6203). Turso's
+**remote** transport is unaffected in both directions: it overrides `create` and
+never enters `fillAutoNumberFields`, so it has neither the defect nor the fix.