Replay semantics behind the illustration
Checked 30 September 2026 against repository head 3018fe73de07232b15157e2c43577832a8a10fa7.
The model
- A competing publication is reported as a conflict. Background sync pauses at a conflict; the application explicitly calls its SDK's conflict-resolution method.
- Resolution adopts the authenticated shared revision. Matching local transactions already present there are recognized by identity and recipe, so they are not applied twice.
- The remaining local transactions replay in order. Their original SQL and parameters run against the new base. SQL expressions are evaluated again; previously computed application values supplied as parameters stay frozen at their recorded values.
- The resolution result identifies already-published, replayed, quarantined and still-pending transactions. Successfully replayed work is local until a subsequent sync publishes it.
Replay is SQL re-execution, not an inferred business-level merge. For example, an application that previously read 12 and calculated 11 has recorded an explicit value if it binds 11 to SET units = ?. Replay keeps that 11. An expression such as SET units = units - ?, with parameter 1, instead subtracts from the newer stock value.
The SDK checks recorded execution outcomes and transaction survival. A constraint failure or replay mismatch rolls back the replay attempt and quarantines its transaction; later queue items can still proceed. Resource failures such as a busy database or I/O error can interrupt replay while preserving pending work. Quarantined transactions are not silently retried. Full diagnostic records follow configured retention limits; safety tombstones prevent reuse of rejected transaction identities.
Verified café examples
Each check used two native Windows SDK databases and a local-directory remote. Both started with 12 units. One device performed its pending update locally; the other published 8 units. The first device then received a conflict and explicitly resolved it.
| Recorded operation | Shared base | Result after resolution |
|---|---|---|
UPDATE stock SET units = units - ?, parameter 1 | 8 | 7; one transaction replayed |
UPDATE stock SET units = ?, parameter 11 | 8 | 11; one transaction replayed |
UPDATE stock SET units = units - ?, parameter 9, with CHECK(units >= 0) | 8 | 8 unchanged; one transaction quarantined |
The example table contained one product row, id = 1. The page shows an explicit WHERE id = 1 to identify that product. Recorded verification results.
These are functional checks, not latency measurements or a certification of every replay path. The installed SDK was built from df3809a06183f35424f6cb3bcd75a11b8c05234d; the current source contract was inspected separately. The landing-page sequence is an illustration of these rules and does not execute a database or contact storage. The earlier SQL section and transfer lab are separately labeled real-engine examples.
The visible sequence starts with 12 units on both devices. The laptop sells four and the phone sells one, giving separate local counts of 8 and 11. The laptop publishes 8 first. After the phone observes a conflict, its application resolves it: adopt 8 and re-run the subtraction to obtain 7 locally. The bucket remains at 8 until the phone publishes 7. The laptop then pulls the published result. The last frame summarizes that publication and pull; it is not a claim that conflict resolution itself instantly updates every device.
Source
- Core contract R5–R6 (private source reviewed; not publicly accessible): ordered replay, frozen parameters, SQL re-execution, quarantine and recovery.
- Public API contract A4, A6 and automatic sync (private source reviewed; not publicly accessible): explicit conflict resolution and observable results.
- Native replay runner (private source reviewed; not publicly accessible): normal completion, quarantine and interruption paths.
- Node conflict-resolution example (private source reviewed; not publicly accessible): detect conflict, resolve it, then sync again to publish.