Document update conflict

Mobile Couchbase Lite
1

Hi.

I’m seeing a lot of “Document update conflict” messages when I do some large scale document changes (e.g. I delete a few hundred docs locally).

They are in my sync_gateway logs:
sg_info.log:2019-02-09T04:47:16.775Z [INF] Changes: MultiChangesFeed(channels: {}, options: {Since:53242 Limit:0 Conflict s:false IncludeDocs:false Wait:true Continuous:true Terminator:0xc4203ef0e0 HeartbeatMs:0 TimeoutMs:0 ActiveOnly:false}) … (to MZyNrBzjOZZl)
sg_info.log:2019-02-09T04:47:16.809Z [INF] SyncMsg: [3810a682] #4097: Type:setCheckpoint –> 409 Document update conflict Time:2.085141ms User:MZyNrBzjOZZl
sg_info.log:2019-02-09T04:47:17.015Z [INF] SyncMsg: [3810a682] #4105: Type:setCheckpoint –> 409 Document update conflict Time:946.986µs User:MZyNrBzjOZZl
sg_info.log:2019-02-09T04:47:17.224Z [INF] SyncMsg: [3810a682] #4106: Type:setCheckpoint –> 409 Document update conflict Time:1.979689ms User:MZyNrBzjOZZl
sg_info.log:2019-02-09T04:47:24.398Z [INF] Changes: MultiChangesFeed(channels: {}, options: {Since:53242 Limit:0 Conflict s:false IncludeDocs:false Wait:true Continuous:true Terminator:0xc421b57080 HeartbeatMs:0 TimeoutMs:0 ActiveOnly:false}) … (to MZyNrBzjOZZl)

I do have ““allow_conflicts”: false,” in my sync_gateway.json file.

This isn’t unique - this topic talked about it.

However, the reason I’ve raised it is:
a) that was quite a long time ago
b) it wasn’t resolved that I could see (although Jens did indicate it was ignorable)
c) he was seeing error messages, whereas I’m seeing exceptions.

In my front end, I create my listener and set a change handler function:

replicator = new Replicator(sync_config);
listenerToken = replicator.AddChangeListener(SyncStatusUpdate);
replicator.Start();

The problem shows up in the SyncStatusUpdate handler…

public void SyncStatusUpdate(object sender, ReplicatorStatusChangedEventArgs e) {
....
if (e.Status.Error != null)
{
    log.Debug("Got a sync error! " + e.Status.Error);

In my logs I see:

Got a sync error! Couchbase.Lite.CouchbaseLiteException: CouchbaseLiteException (LiteCoreDomain / 26): Document update conflict.

I’m fine if this is an ignorable error… but it seems rather strange to have an exception object. Also… I’m having to write code of the form:

if (e.Status.Error.Message.Contains("Document update conflict")) {
    ...ignore the error....

which is fragile to any future changes you make in messages. There is an error code “26” - is that reliably and uniquely associated with ignorable sync errors?

Am I misunderstanding what’s going on here?
Thanks for your help.
Paul.

2

This is pretty normal.

The Sync Gateway logs show that it’s rejecting updates from clients that conflict with the current server revisions.

On the client side, it will log that error and pass it to the app callback; but if the replication is push+pull, the puller will bring in the current server revision and resolve the conflict. Then the resolved revision gets pushed.

3

@jens Ok, that makes sense. Thanks for the response.

Is there a way I can differentiate between problematic errors and ignorable conflict errors in the callback? Right now I’m searching the error message (see above), which feels fragile.

BTW - V2 is soooo much better than V1. Nice job.

4

That looks suspicious to me and there might be an issue with the library. The error code indicated is “26” which means “remote error” but really it should be “8” which means conflict or possibly 10409 (remote conflict). @jens Could you confirm that? I wonder if LiteCore is overgeneralizing here…

5

Also, in the next release these callbacks have been enhanced and this error will be sent on a different callback. I have confirmed that the error code is correct on that one. In the meantime, if the error is showing 26 then your “flimsy” option is the only choice. Technically it will continue to work since that type of error will no longer be passed to the status changed callback though (since it doesn’t affect the status of the replicator). I guess the thinking is that any error in there is stop-worthy.

6

Thanks @borrrden
I’ve left in the "flimsy " option and ignored the conflict errors. Replication is now as smooth as silk.
I look forward to the next version.
Cheers.
Paul.