Unity Conflict Handling

Treat conflict handling as a normal part of the Unity save flow.

A stale baseVersion is not a transport failure. The Unity SDK returns the cloud conflict branch plus typed conflict details so the game can reconcile intentionally.

Conflict Example

Use this pattern for explicit conflict recovery.

JAVASCRIPT

var result = await client.SyncAccountSlotAsync(
    accountId,
    accountSessionToken,
    slotId,
    new PersistlySyncAccountSlotRequest(
        dataJson: nextDataJson,
        baseVersion: local.Version,
        slotInfoJson: local.SlotInfoJson
    )
);

if (result.Status == PersistlySyncStatus.Accepted)
{
    local = result.Slot;
}

if (result.Status == PersistlySyncStatus.Conflict)
{
    var cloudSlot = result.Slot;

    if (result.Details?.Reason == PersistlySyncConflictReason.BaseVersionMismatch)
    {
        // Keep cloudSlot as the baseline. If the player keeps local edits,
        // retry with baseVersion: cloudSlot.Version and the local draft data.
    }
}

Rules

These are the conflict semantics the Unity integration depends on.

A 409 from the runtime becomes PersistlySyncStatus.Conflict in the Unity SDK, not a generic transport failure.

result.Slot is always the cloud conflict branch. Treat it as the new baseline before retrying local edits.

result.Details?.Reason tells you why the conflict happened and is currently BaseVersionMismatch for stale sync attempts.

The right recovery order is: keep the cloud branch as baseline, decide what to do with unsynced local edits, then issue a new sync if needed.