Is it possible to restart device sync without termination - after the problem with unsynced documents?

Is it possible to restart device sync without termination - after the problem with unsynced documents?

if 100k items are unsynced then we get a notification:
‘A Sync process has failed and cannot be restarted’

Then, through mongodb compass, we remove documents from the database that were created with a incorrect data structure (we remove them from normal collections, not from the unsynced_documents collection).

We then try to restart the sync, but it fails. We have to do a terminate and enable device sync from scratch - then we lose the data stored locally on the phones while device sync was not working.

Are we able to restart sync without terminate so that we don’t lose locally saved data?

1 Like

I have the same issue

1 Like

Hi, when you click “Restart Sync” does it fail again with an error about hitting the unsyncable document count? The issue is that it is still processing through the oplog to get to the events generated by you making them syncable (or deleting them in this case).

If this is the case, you can give me your application ID and I can artificially increase the maximum number of unsyncable documents and you should be able to continue syncing without restarting sync.

The app ID is just the ObjectId hex in the URL when you are in the Realm/AppServices UI /groups/${group_id}/apps/${app_id}. This is safe to send here but you can also DM me on the forums if that is preferred.

1 Like

Yes, it fails again. app_id: 63a5cdc25c766c7a43776b1c

please let me know if you find any solution

1 Like

Hi, sync is enabled and running on that application. Did you terminate and re-enable sync?

Like I said I can allow you to move past this issue but I am not seeing evidence that the application you mentioned is running into this.

Yes, such a problem occurred a few days ago and we wanted to look for solutions for the future and protect ourselves from similar situations.

Got it. Yeah, we can always raise these limits for individual customers. We added the hard limit because at a certain point, it is good to fail loudly and let the customer know that a large percentage of their documents are not being synced due to the fact that they do not adhere to the schema.

Could I ask what the issue was that led to so many documents being unsyncable? We have had some customers run into this when adding a new required field. We have tried to make this clear in the docs but are thinking through some other ways of preventing this in that case. If you are curious and this is what you ran into here are the docs: https://www.mongodb.com/docs/atlas/app-services/sync/data-model/update-schema/#add-a-required-property

2 Likes

There were documents in the database whose _id fields were of type ObjectId instead of string. Unfortunately, there was a vulnerability in our code that created documents without _id.