Unable to PUSH document changes. CBL 2.8 conflicts with newer server revision

Mobile Couchbase Lite
1

Hello!

I am migrating my app from CBL 1.4 to CBL 2.8!

I am getting ReplicatedDocument{1d34f636-fdb2-420d-b773-01cd9e8ea14a,err=CouchbaseLiteException{CouchbaseLite,10409,'conflicts with newer server revision

I am using one-shot PULL-PUSH replication. So first I perform PULL and only after pull, i perform push replication

I checked CBL 2.8 revision and I got
16-47622201e8b65b9353c9c74bb08304f4a86927b9

(thats how i got it: DatabaseManager.getDatabase().getDocument(“1d34f636-fdb2-420d-b773-01cd9e8ea14a”).getRevisionID())

On Sync Gateway 2.0 side I got following info:

{
“rev”: “5-cac1e2f6a087281efb60b74b83b818bc”,
“sequence”: 2431630,
“recent_sequences”: [
2431509,
2431529,
2431543,
2431620,
2431630
],
“history”: {
“revs”: [
“3-e9f045e48cd5432ecf6a99db665e0cf3”,
“5-cac1e2f6a087281efb60b74b83b818bc”,
“4-b9f07e6265088815f3fc32c1beb60d1cabe51e24”,
“1-e05fe89d3da096c0fdd097bbb7980509”,
“2-7f73bcd11343728b3c8c0f70def8ab1883a600a8”
]
…
}

What may be the reason for such behaviour? Why if server revision is newer, the PULL replicator did not get it from server?

P.S.: I am just testing so I got only 1 mobile device and a web site, which can also modify docs.
Never get in a such situation during CBL 1.4 era

Also allow_conflicts option in my sync gateway config is missing, means that it is set to true as per documentation

2

If you are using 2.x version of couchbase lite clients, the “allow_conflicts” is always false (We should make that clearer in our documentation).

Conflicts in 2.x are automatically handled by the system and you have option to override it. More details in our docs. You must have push-pull replication - conflicts are resolved on pull. So when CBS rejects the document update with a 409, CBL will resolve the conflict and push up winning revision. This blog describes automatic conflict resolution - which of course you can customize as described in the doc link.

Tagging @ibsoln for documentation impact,

3

@priya.rajagopal So if I understand correctly we should change our replication from PULL-PUSH to PUSH-PULL in order to prevent such problems as I described? Is it so?

P.S.: I read documentation you provided and still did not get why PULL-PUSH replication does not work.
So if conflict resolves on pull, then my conflicts should be resolved first during PULL replication and then pushed during PUSH, no conflicts should be present?
May be I have some misunderstanding?

4

Not sure what you mean by “pull-push” versus “push-pull”. The only supported replicationTypes are pushAndPull, Push and Pull.
So you use pushAndPull if you want bi-directional communication. My response was related to your earlier comment.

Also allow_conflicts option in my sync gateway config is missing , means that it is set to true as per documentation

It is incorrect that allow_conflicts is “true”. There are no conflicts with 2.x clients as described earlier. Conflicts are automatically resolved at the same of document save

5

@priya.rajagopal By PULL-PUSH I mean that I first perform one shot PULL replication and only after it successfully completed I perform one shot PUSH replication.

So if i understand correctly during one shot PULL stage conflicts should be resolved and then I can perform one shot push replication part

6

I do not understand why you are setting up two separate unidirectional replications. Use bi-directional replication as it will also ensure that your endpoints are eventually consistent (and its much more resource efficient than two separate replicators). Having separate unidirectional replications makes sense when changes are one-way. For two way changes, you cannot guarantee the order of changes and you can end up in an inconsistent state.
Pull doesn’t stage conflicts. Conflicts are detected and rejected by SG on push and conflicting revisions are subsequently pulled and resolved on client… So have a push-pull bi-directional replicator that will ensure that. Would suggest reading the blog and docs that i shared earlier on how this works.

1 Like