Mango queries with conflicts: true return documents that do not have conflicts

[garbados]

Queries to the /{db}/_find endpoint that set conflicts: true return documents that do not include conflicts. I have documented a test case here that reproduces the issue.

The documentation in cloudant/mango indicates that this is expected behavior:

conflicts (optional) (default: false) - boolean, whether or not to include information about any existing conflicts for the document.

However, it sure would be nice to issue queries that return only conflicted documents that match the given selector.

Expected Behavior

A query setting should exist to filter query results to only those that have conflicted and match the given selector.

Current Behavior

Setting conflicts: true returns documents with and without conflicts, such that the user must perform a second query to /_all_docs to determine which documents actually have conflicts.

Possible Solution

Setting onlyConflicts or otherwise-named query value should cause CouchDB to filter results of a query to only those documents that match a given selector and which have conflicts.

Steps to Reproduce (for bugs)

I've developed a test case here using node.js.

Context

Detecting conflicts requires finding them first. In large databases, performing one query to find documents that may have conflicts and then another to determine which of them actually do creates considerable request overhead for applications attempting to detect or resolve conflicts proactively.

Your Environment

• Version used: 2.1.1-180a155
• Browser Name and version: N/A
• Operating System and version (desktop or mobile): Ubuntu 16.04.3 LTS
• Link to your project: gist

[davisp]

Going over this on IRC I'm pretty sure the root cause of this bug is here:

https://github.com/apache/couchdb/blob/master/src/mango/src/mango_cursor_view.erl#L285-L287

Using a partial filter index and removing the _conflicts check results in the correct results. Theoretically specifying r=2 in the options would also fix it but Fauxton apparently has issues encoding that and is passing [50] (i.e., ASCII "2") which is then ignored by Mango.

[wohali]

@garbados can you see if specifying r=2 in the options works with this, when NOT using Fauxton, as @davisp suggests above?

[garbados]

Here are the index and selector I am using to detect conflicts:

// INDEX
{
  "index": {
    "fields": [
      "_conflicts"
    ],
    "partial_filter_selector": {
      "_conflicts": {
        "$exists": true
      }
    }
  },
  "ddoc": "conflicts",
  "type": "json"
}

// SELECTOR
{
  "selector": {
    "_conflicts": {
      "$exists": true
    }
  },
  "use_index": "conflicts"
}

Given a database with conflicted documents, using this selector with this index, whether with r=2 or conflicts=true, returns this result:

{
  "docs":[],
  "bookmark": "nil"
}

I'm not sure what I'm doing wrong relative to the prescribed method.

[fynnlyte]

I was tired of adding and deleting DDocs when searching for conflicts in a DB so I've tried this simple Mango-query in Fauxton:

{
   "selector": {
      "_conflicts": {
         "$exists": true
      }
   }
}

But no documents were returned even though conflicts existed. Might be because the "_conflicts" - key is not visible by default. It would help a lot if this was possible via Fauxton.

[janl]

Closing in favour of #1425