Cloud Sync Conflict Convergence

Description

Cloud Sync Conflict Convergence applies remote Dotabase entities using deterministic timestamps and content-hash tie breaks so replicas reach the same result.

The apply service normalizes an incoming record, compares it with the tenant-scoped local entity, and chooses a winner using an ordering every replica can repeat. Exact replays become idempotent outcomes; equal timestamps use semantic hashes rather than arrival order. When both versions represent real competing changes, the service records a conflict receipt while still applying the deterministic winner.

User Story

As a multi-device user, I reconnect after offline work and receive a consistent workspace even when both sides changed the same record. My sync transport delivers records in whatever order connectivity allows. The apply service evaluates each version under the same tenant and entity rules, journals meaningful collisions, and updates derived identity counters when needed. I walk away with the same durable state on repeated delivery and a receipt to inspect when last-write-wins discarded a competing edit.

Extension Surface

Fixed core: conflict ordering and normalization must be identical across replicas to guarantee convergence.

packages/dotabases/src/services/sync-apply.ts centralizes this invariant and is callable by transport compositions, but it does not expose the ordering algorithm as customer configuration. Allowing replicas to choose different timestamps, hashes, or collision rules would destroy convergence, so extension belongs at the transport boundary rather than inside resolution.

Capabilities & Limits

• Capability: Executes the scoped workflow described above through the cited live implementation paths.
• Capability: Preserves typed validation and applicable tenant, schema, lifecycle, or service boundaries.
• Limit: Uses last-write-wins rather than field-level collaborative merging. Blob locator fields are excluded from semantic hashes. The service accepts repeated and reordered delivery, resolves supported entity kinds, handles row human-ID collisions, and writes journal evidence for true conflicts. It does not perform character-level or property-level merges, choose intent from two edits, or synchronize blobs by itself. Correct timestamps, tenant identity, and compatible normalization are still prerequisites.

Implementation Map

• packages/dotabases/src/services/sync-apply.ts
• packages/db/src/schema/conflict-journal.ts
• packages/db/src/schema/dotabases.ts

Related Features

Synchronizes Dotabase Workspaces; transport and binding management live outside this lane.

Operationally, these relationships preserve a clear ownership boundary around Cloud Sync Conflict Convergence. Neighboring features can invoke, supply, or consume its results, but `packages/dotabases/src/services/sync-apply.ts` remains the grounded implementation authority for this capability. That distinction prevents the catalog claim from widening into adjacent rendering, transport, or governance work. Teams can therefore combine the feature with the named dependencies while still diagnosing configuration, validation, and lifecycle behavior at the package boundary that owns it.