Struggling with recovering from server-sided sync outages

MongoDB Atlas App Services & Realm Atlas Device Sync
,
1

I am using unity with realm 10.7.1 and currently testing my realm controller against server-sided “Realm Sync” outages. To simulate this I am switching sync off and on in the browser.

Is their a strategy/pattern to address the outage scenario? I am asking for preventing data loss.

The behaviour I would favour, should allow continued work with the local realm file and
offer some kind of conflict resolution when sync is up and running again.

I tried different concepts. The outcome was realm forcing the outdated cloud data into the local realm file and thus erasing the gained progress. Or the outcome was getting an empty local realm when fetching it, because the background synchronization was not done yet, because sometimes sync took extra time to re-launch. (Listening to session.error, recording that incidence and insisting on GetInstanceAsync followed by SyncSession.WaitForDownload the next appstart(s)/login(s) could not avoid this!)

Frustratingly, from a user point of view: everything seems to be fine and working, but suddenly on a appstart “like any other” realm’s self-healing process kills the local data and overwrites it with the age-old, pre-sync-outage cloud data!

What should I do? Please, can anyone explain how to handle this scenario?

2

Are you talking about service outage - e.g. when the device is offline or AWS is down or are you talking about restarting sync on the server? In the first case, Realm will automatically resolve conflicts and the final state should be a combination of the local changes and the server changes based on deterministic rules. E.g. if two clients changed a property on the same object, the one that did it last will “win”. You should be able to test that out by turning on airplane mode or disconnecting your device from the internet - when a connection is reestablished, server and local changes should be merged (there might be some delay as we’re doing exponential backoff for reconnections).

If you’re talking about terminating and reenabling sync on the server, then the server changes will always overwrite the local ones. This is due to the fact there’s no way to merge those in a deterministic and “correct” way because the timestamps for all updates will be set to whenever sync was reinitialized. Once you ship your app in production, it is not expected (and strongly discouraged) that you terminate and reenable sync for this reason.