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

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?