Getting information for rejected documents in push process

Hi,

Is there a way to learn whether a document is rejected by sync gateway in cb lite side?

Let’s say we have a sync gw function which validates the json fields and the data that pushed from client is not valid. As a result, it is simply rejected. In this case, we may want to delete the invalid version of the document from cb lite db for that specific client. Is it possible to do that?

Thanks.

1 Like

You could listen to replicated events which indicates replication status of a document (pushed, pulled, error)

Thanks for the answer.

I’m also wondering that is there a some kind of recovery mechanism / strategy that we can use. I’m asking this because if a document is invalid and we know rejection occurred thanks to your above solution, we may want to revert back to revision which is hold by server.

Thanks.

Well, if the server has rejected the new revision, doesn’t it imply that it is holding the previous revision ?

Yes, it is holding the previous revision but we also want to get rid of problematic document in client side. The issue is that displaying the invalid json to mobile user might be misleading. We guarantee that the server will always have the valid data but on the other hand, if something is wrong in mobile side, our aim is just ignoring client changes and be in line with server side on tablet.

From a user experience perspective, it would seem like the right thing to do would be to inform the end user that the document is invalid and provide an opportunity for user to rectify the document that the app can attempt to push again. Silently reverting back the document to previous version would be confusing to the user and besides, it does not serve the original intent of the mobile user.

That said, we are not a “version control system” in the sense you can’t revert back to a previous version. You would have to do it within your app - maintain a shadow copy of the previous version in a “backup” instance of Couchbase Lite. You “commit” the client side copy to the backup only when replication is successful. If not, you read from backup copy and update the local version.

I agree with you. We should inform user that his/her changes won’t be synced to server due to a bug for example. We can put a button which discards user’s changes and pull the original - valid revision of that document from server.

To realize what I mentioned above, can we leverage purge() API in client side? Then, the replicator might get the document through sync gateway because I don’t have that specific document in my local db. Is my assumption correct? :slight_smile:

Thanks.

Not unless there is an update on the server side that will trigger a sync. The checkpoints are all caught up so locally purging doc will have no impact on replication

Again, from a user experience perspective, I think app should present the current (invalid) version of document to user and provide them the opportunity to edit. That would be preferable so the user does not lose all their changes and have to redo all of it if it was just one edit that was the issue. It’s also possible that a user may not even recall what they had edited.

It’s best if the app simply doesn’t create docs that are rejected by the server — it shouldn’t be violating the data schema or trying to make invalid changes, for example.

It sounds like this is unavoidable in your app, though? The SG sync function may reject docs for reasons that you can’t detect ahead of time?

I ran into this issue, too. E.g creating docs in an Android app which are rejected by the SG. This was also the case of older Android app versions which didn’t add some fields to a document but the SG function was already updated. As far as I know in CBL 1.x there was only a warning the logcat but no listener. Has this changed in 2.x? Can I listen to document rejections and then act on them? Code snippet or documentation would be great!

See the accepted answer on this thread.

1 Like

Yes, as you said, it would be just a bug. Otherwise, another approach is needed like Priya suggested.