Race condition between replicator write and local write

Mobile Couchbase Lite
1

We are encountering an issue where the replicator syncs changes while we are simultaneously writing changes to the same document. Although we are aware of concurrency control options such as lastWriteWins and failOnConflict, these do not resolve our problem. Here is the scenario:

  1. Client A makes changes to Doc1, Doc2, and Doc3.
  2. Client B’s device replicator initiates.
  3. Client B runs business logic in the pull filter, identifying the need to make changes to Doc1, Doc2, and Doc3.
  4. The application updates Doc1, Doc2, and Doc3, and saves the changes.
  5. The replicator’s pull filter returns true, overwriting the changes made to Doc1, Doc2, and Doc3.

In essence, both the replicator and the application are making changes to the documents concurrently.

One potential solution is to return FALSE for the affected documents in the pull filter, preventing the replicator from pulling changes when certain business logic conditions are met, thereby allowing the application to make custom changes. However, this approach seems fragile and limits the pull functionality.

  1. Is there a way to specify: First sync, then let the application overwrite ?
    I assume this will involve some sort of serial access, but we also don’t want to do long running operations as part of the pull sequence.
  2. Is there a callback where CBLite which emulates: didWriteToDisk

What is the official recommendation for handling this situation?

2

One potential solution is to return FALSE for the affected documents in the pull filter

We do not advise to use the pull filter for this.

The 1-5 scenario described above should result in a conflict. I believe this might be exactly what you are looking for - Handling Data Conflicts | Couchbase Docs - specifically LocalWins at the collection config level, CollectionConfiguration.conflictResolver .