DiscardLocalResetHandler strategy discards the local changes and gets a fresh copy of the realm stored on the sync server. A destructive schema change makes this impossible as downloading the fresh realm is impossible given the mismatching schemas. In that case, your client and server need to re-align with the schema first, then sync can be restarted.
I do destructive change and I receive the HandleBeforeResetCallback but I never receive the HandleAfterResetCallback even If I do not close the app for a long period of time. Besides, when I close the app and reopen it again I receive the HandleBeforeResetCallback again
Generally, when the
DiscardLocalResetHandler strategy fails because of an error, it fallsback to the ManualResetFallback. So it’s normal that you don’t see the
OnAfterReset being triggered. However, you’d see the
And eventually, when I close the app and open it for the third time I get the app with proper sync.
This is a little strange. Are you sure that in the meanwhile you haven’t updated the schema on the client to match the server?
As a little conclusion,
DiscardLocalResetHandler is expected to be really useful in a situation where the client and the server don’t share anymore the same history; but still share the same schema.
It’s generally really helpful to have an overview of what could cause a client reset. I’d recommend to take a look at our docs about this subject.
Additionally, we specifically explain in our docs that a destructive schema change is not something that
DiscardLocalResetHandler can handle, and it’ll fallback to