# Content temporarily unavailable
# Paced persistence serialization review

Reviewed product commit: `632e46944241e64d91f46fd874de90d70d226cf8`.
Base: `9e8ed997885fb46ac98ec85906f4ca4f662e7cce`. The review record and
changeset follow that product commit. The primary executable owner is
`packages/db/tests/paced-mutations-oracle.test.ts`.

## Contract and result

The paced mutations guide promises at most one pending and one persisting
transaction for debounce and throttle. The queue strategy promises serial
persistence. Issue #2058 demonstrated two concurrent backend handlers for
debounce and throttle. A manual rollback exposed the same overlap in queue:
the public receipt rejected before its active handler returned, so the next
handler started early.

The repair separates admission from persistence. A rejected paced call owns an
isolated transaction, while admitted calls can merge into the one pending
transaction. Debounce and throttle reserve a leading edge before `onMutate`
can reenter. A shared serial pacer waits for actual `Transaction.commit()`
completion, rather than receipt settlement, before it starts another handler.
Queue uses that same completion boundary. A manual rollback still rejects its
public receipt immediately.

## Law, histories, and observation cuts

The independent two-call rule starts the successor only after both its timer
edge and the first handler's release. The oracle enumerates 24 successful
hold/release histories across debounce and throttle. It crosses leading,
non-leading, and omitted-leading options, with release before, at, and after
the edge. The model computes `max(eligibleAt, releaseAt)` without importing
the production scheduler. The immediate handoff is the chosen pacing policy;
the guide's serialization promise alone supplies the lower bound.

The production driver uses real Collections, strategies, and transactions.
It controls handler promises and a virtual clock. At admission, the timer
edge, handler release, and final drain, it checks every handler start, active
handler count, transaction state, receipt outcome and identity, and optimistic
rows. Adjacent histories distinguish a renewed debounce quiet period, throttle
spacing from actual starts, and dropped-call admission isolation. The
settlement grammar crosses both factories, leading modes, same/distinct keys,
first-handler success or rejection, and pending cancellation. Manual rollback
crosses debounce, throttle, and queue. Nested `onMutate` checks one merged
leading write, no stale timer, and a later usable admission.

Original production fails 18 of the 24 held-edge histories at the concurrency
assertion. The six release-before-edge controls pass. Before the final repair,
manual rollback fails at the active-handler assertion for each of the three
strategies. Nested admission fails for debounce and throttle. These are
assertion kills at the promised intermediate cuts, not timeouts. The repaired
owner and ordinary pacing tests pass 136/136 on the reviewed base. Focused
TypeScript, ESLint, Prettier, and the DB package build pass. The build reports
non-fatal missing Expo example configuration warnings.

## Oracle guide audit

| Requirement | Result for this owner |
| --- | --- |
| ORC-001 | The guide supplies serialization and timing authority. The opening oracle prose and coverage map state finite limits. |
| ORC-002 | Expected times come from timer eligibility and handler release, not a production pacer or classifier. |
| ORC-003 | Opening prose states the contract; nearby model, action grammar, production driver, and assertions remain distinct. |
| ORC-004 | The 24-cell matrix is bounded enumeration with explicit release offsets. It does not claim random reach. |
| ORC-005 | Real production entry points reach held handlers. The recorder retains ordered starts and intermediate receipts. |
| ORC-006 | Original overlap, early release after rollback, and duplicate leading starts fail their intended assertions. |
| ORC-007 | No important random property is introduced. Named finite tests provide direct replay. |
| ORC-008 | The two-call expected rule is a prerequisite calculation, not a copied production state machine. |
| ORC-009 | Model `pendingIds` combines optimistic mutations. Handler completion and public receipt settlement stay separate. |
| ORC-010 | Cleanup releases held promises and preserves a primary assertion when cleanup also fails. |
| ORC-011 | A second equivalent formulation is unnecessary for the max-prerequisite rule. The issue's direct two-call probe provides a separate public concurrency observation. |
| ORC-012 | This record states the bounded closure, kills, checks, limits, and each guide outcome for the reviewed product commit. |
| ORC-013 | Edge-before/at/after releases, renewed quiet, delayed actual-start spacing, and nested admission reject nearby wrong designs. |
| ORC-014 | The claim is limited to controlled DB source execution. No real-server, framework, or npm handoff is claimed. |

The repaired source paths have no known reachable counterexample in the named
grammar. The coverage map owns provider echo, cleanup during a held handler,
longer arbitrary bursts, held default options, and multiple-manager histories.
Those gaps limit the evidence; a passing finite suite does not prove every
possible history. Server ordering, framework scheduling, and published npm
behavior require separate receiving witnesses.