Synchronisation

SyncSlotAsync, the four directions a sync can take, and why direction is decided by generation and revision rather than by clocks.

Cloud NexusForge Persistence 0.2.0 Updated

One call, four outcomes#

csharp
var outcome = await sync.SyncSlotAsync(new SaveSlotId(class="tok-str">"default"));

switch (outcome.Value.Direction)
{
    case CloudSyncDirection.LocalAdopted:      break;   // remote was newer: the local slot now holds it
    case CloudSyncDirection.RemoteUpdated:     break;   // local was newer: the service now holds it
    case CloudSyncDirection.AlreadyEqual:      break;   // nothing to do
    case CloudSyncDirection.ConflictPreserved: break;   // both survive; see conflict resolution
}

Never by wall-clock time#

Direction is decided by the generation and revision carried in the record. Two devices whose clocks disagree by an hour must still agree about which save is newer, and a clock change must never make older data win. That property is tested with deliberately skewed clocks. Available

What a sync does not do#

  • It does not merge your model. Records are whole documents; the framework decides which one wins, not how to combine two.
  • It does not fight a refused precondition: a lost race is reported, not retried over the top.
  • It does not carry on silently when credentials expire: on a 401 the authentication provider is asked to refresh exactly once, then the call is abandoned. There is no refresh loop.

Inspecting and repairing state#

csharp
var state = await sync.GetStateAsync();          // what is outstanding, per slot
await sync.RemoveRemoteAsync(slot);              // deliberate, explicit

The sync journal beside the saves records what has been done, so "what is actually on the server" is answerable rather than guessed at.

Next#

Something wrong on this page? Every page here describes behaviour that is checked in the repository. If a page and the package disagree, the package wins.

Report a documentation problem · Frequently asked questions · Troubleshooting