Discard vs Recover: Choosing a Realm Client Reset Path When a Failed Upgrade Leaves Local Writes Unsaved

Question

Choice Between Discard and Recovery After a Failed Upgrade
A failed app upgrade that changes the sync schema or leaves the client and server out of step can force a client reset in MongoDB Realm / Atlas Device Sync before the local realm can sync again. The immediate engineering decision is whether to discard unsynced local writes and download a clean server copy, or to recover them by backing up the local file, downloading a fresh copy, and attempting to reintegrate the backup.
Discarding is deterministic and bounded because it runs no conflict logic, but it trades away every offline write made during the broken-upgrade window. Recovery preserves user data, yet it re-inserts objects that may have been deleted or edited on the server. Reintegration is best-effort and can fail per object, so the app must still handle partial failure.
The unresolved point is the conflict policy for a locally modified object that was remotely deleted during the recover path. There is no single documented default across SDKs: the app must choose to auto-accept the reintegrated state, prompt the user, or fall back to discard. Exact API names, defaults, and whether recovery is preconfigured or handler-driven also differ between legacy Partition-based Sync and Flexible Sync, and across Swift, Kotlin, JS, and .NET, so the decision depends on the exact SDK version being shipped.
For a given SDK version, should an offline-first app favor discard for predictability or recover for data preservation, and how should it resolve the locally-modified-versus-remotely-deleted case when reintegration is partial? Which client-reset handler semantics apply in the exact version being shipped?

Siddharth · Answer

Answer
Favor discard unless you are shipping a Flexible Sync SDK version with a tested custom client-reset handler. Discard is deterministic and bounded; recovery is best-effort and can reintroduce stale objects. For the locally-modified-versus-remotely-deleted conflict during partial reintegration, accept the remote deletion unless your handler explicitly overrides it, because keeping the local copy can resurrect data the server intentionally removed.
Confirmed facts

Discarding the local realm guarantees a clean sync state and runs no conflict logic.
Recovery preserves user edits but requires backing up the realm, downloading a fresh copy, and attempting reintegration, which may fail per object.
Legacy Partition-based Sync defaults to discard; recovery must be implemented manually.
Flexible Sync exposes a client-reset handler that can perform recovery, but the exact API name and defaults differ by SDK and version.

Steps for this case

Confirm the SDK version and sync model in your build files or runtime logs.
If you are on Flexible Sync and have a recovery handler, back up the local realm file, download a fresh server copy, and reintegrate local objects one by one.
If you are on Partition-based Sync or lack a handler, discard the realm and let the next sync download a clean copy.

Conflict policy during partial reintegration
When a locally modified object was remotely deleted, the safe default is to accept the remote deletion. If you must preserve the local change, flag it for user review rather than silently overriding the deletion. Because reintegration can fail per object, your handler must track which objects succeeded and which failed, and remove or quarantine the failures.
Which SDK version and sync model are you shipping? This determines whether a custom recovery handler is available and what its exact semantics are.

Discard vs Recover: Choosing a Realm Client Reset Path When a Failed Upgrade Leaves Local Writes Unsaved

Choice Between Discard and Recovery After a Failed Upgrade

1 answer

Answer

Confirmed facts

Steps for this case

Conflict policy during partial reintegration

Your perspective belongs here.

0 question comments