Resolved conflicts in CouchDB not reflected in TouchDB

[Matt Quinn]

Out setup is a CouchDB server with many Android and iOS TouchDB clients. The clients keep push and pull continuous replications running. We have a separate follower process (on another server) that follows Couch's changes feed and, when it encounters a document conflict, merges the document and deletes the conflicting revisions in a bulk update (following the pseudocode in the wiki).

We would expect that this change would get reflected on our devices, removing the conflict, but although we get the follower's updated revision, the conflicting revision never gets deleted, so we continue to see conflicts on our Android devices.

Simply deleting a (conflict-free) document in CouchDB works fine, so it seems to be deleting conflicting revisions that is the issue. I'm pretty sure we aren't seeing this issue on TouchDB-iOS, where the local conflict is resolved once the pull comes through.

Thanks - I'd be happy to provide any more info that might be useful.

[Jens Alfke]

There were some significant changes in TouchDB last fall about how to determine which revision of a doc is the default "winning" one if there are conflicts. These definitely aren't in the Android version yet since they happened some time after Marty stopped updating it.

[Traun Leyden]

so we continue to see conflicts on our Android devices.

Hmm, sounds like a bug.

Can you be more specific about what api call you are calling or exactly how you are determining that the document is in a conflicted state?

[Matt Quinn]

@tleyden We first noticed the problem when calling CouchDbConnector's "get" method (the Class, String override), which kept returning old revisions. Changing the call to the Class, String, Options override, with Options().includeConflicts(), we see that doc.getConflicts() has revisions in it.

The whole process:

1. Android creates local revision 2-a of document "foo", and some other device creates local revision 2-b.
2. Both devices push to the server, creating a conflict.
3. Our change feed listener sees the conflict, and issues a bulk change that picks 2-b as the winner (creating 3-a) and deletes 2-a.
4. Android, which is continuously pulling, gets the change.
   At this point, my (possibly incorrect) expectation is that Android's state should have been updated to match the server, and couchDbConnector.get(Class, "foo") should return revision 3-a.
   But, couchDbConnector.get(Class, "foo") returns revision 2-a still.
   If we call couchDbConnector.get(Class, "foo", new Options().includeConflicts()), the returned document's getConflicts() contains 3-a, so we can see we've still got a conflict locally.