What is the best practice for handling a revision rejected from the sync function? At the moment when it happens the document stop syncing and won’t get new revisions. It is stucked to the rejected revision.
I can catch the error in the addDocumentReplicationListener but I don’t know how to handle it
The approach depends on why exactly it is rejected. You might want to check whether there are schema violations (e.g. required properties, constraints on properties, etc) or access control violations (i.e. this user doesn’t have permission to mutate this document) that leads to the rejection.
Regardless the motivation of rejecion, in any case my goal is to prevent document to stop syncing, but I don’t know how to do it. Maybe it can be by reverting the document to the previous revision, but again I don’t know how to do it.
Can you clarify what you mean by prevent document to stop syncing? You can allow the rejected document to (re)sync again by updating the doc so that the replicator will push the updated version to Sync Gateway again or resetting the replicator’s checkpoint using Replicator’s start(boolean reset) method. This will cause the replicator to sync from the beginning again.
Reiterating what Lauren mentioned, it is important for app to react appropriately to the reason for the rejection. There may be several reasons for a document getting rejected, so for instance, if the document is rejected because the user is forbidden from syncing because of access control violation, then “reverting a document to previous revision” (which would be essentially mutating the document to undo the changes) wouldn’t be the best course of action.
Note that the sync function is the primary means of access control enforcement so if a client is prevented from syncing then its important to react the right way.
Hi Priya, sorry but I don’t get why reverting the document wouldn’t be the best course of action. If a user does not have the permission to update a document, or the document is filled with wrong properties, then what is the best course of action?
I agree that the application should not allow the update in first place, and should guide the user with proper ux/ui. But if for any reason the user succeeds, then I see no other solution. Am I missing something?
If a user is forbidden from syncing with sync gateway then “reverting” will not help. The subsequent push of update will be rejected. Also to be clear on what “reverting” is in this context - couchbase isn’t a version control system so you can’t go back or revert to a previous version of the document. So reverting a change would essentially be the app making an update to the document to undo previous changes or making a valid change - that mutation will trigger a push oh document. Depending on the original reasons for the rejection by sync gateway, that version may or may not go through even the second time around
Ok, now I can get where the misunderstanding is. By “reverting” the document I don’t mean creating a new revision with the same content of the previous one, of course that will cause a new push of update that will be rejected. What I mean is what Lauren suggests: resetting the replicator’s checkpoint. I made a test where in case of push error the document is purged and checkpoint reset, this causes the replicator to sync the document again and get back to the previous revision that all other devices have.
If this is a wrong approach, and also mutating the document again is a bad one, what do you suggest?
Not necessarily. The push of the updated version of document that undoes the changes will not get rejected unless the rejection was because of access control issue. If it is access control issue, then resetting of checkpoint will not work either.
Yes- That will work but resetting checkpoint can be fairly expensive because an attempt to resync everything from 0 is made (documents themselves are not resent but there is work done to reconcile all revisions from 0). So its more of a “maintenance API”.
So if you envision this to be a common occurrence . I would suggest the app to react appropriately to the reason for rejection - giving end user appropriate feedback would be better user experience.
So if sync function rejected the document because user tried to modify a property that they shouldn’t have, then silently ignoring change is not helpful.
Thank you @priya.rajagopal now I can really get your point about access control issues.
But what if the rejection is not an access control issue, so it’s not rejected by the sync function, but the error is
Error Domain=CouchbaseLite Code=10409 "conflicts with server document" UserInfo={NSLocalizedDescription=conflicts with server document}
, error: Error Domain=CouchbaseLite Code=5003 "connection timed out" UserInfo={NSLocalizedDescription=connection timed out}
the only way to respond properly will be by resolving the conflict on the device application and push a new revision?
(our SG has allow_conflicts=true)
Yes. New resolved revision is automatically pushed up if you have push-pull replication
On 2.x, that config does not have any affect. With 2.x SGW and CBL, conflicts are resolved on save