View query with reduce and group and unordered list of keys yields bad results

View queries with reduce and group set to true, and parameterized by a list of keys not in ascending order, can produce results that are not properly reduced. This has been verified in the management console directly, and thus is not client-specific behavior.

Steps to reproduce (management console only) on a multi-node cluster: 

1. Create six documents with keys named "scratch:1" through "scratch:6" and the following document structure for each: 

{"type":"scratch","fk":0} 

2. Edit the documents so that three of them have the value 0 for the "fk" key; two have the value 28, and one has the value of 74. (These are arbitrary values but multiple documents must share these to make the problem occur.) 

3. Create a view with the following map function: 

function (doc, meta) { 

    if (meta.type == "json" && doc.type == "scratch") { 

        emit(doc.fk); 

    } 

} 

Set the reduce function to the native '_count'. (This problem has been seen on complex custom reduce functions as well; this is a minimal test case.) 

4. Query the full cluster data set with the following parameters: 

reduce = true 

group = true 

keys = [0,28,74] 

Observed outcome: the results correctly produce [{"key":0,"value":3},{"key":28,"value",2},{"key":74,"value":1}] though the order of these results may be different. 

5. Change the 'keys' parameter to the following: [74,28,0] 

Observed outcome: the results contain duplicate rows for one or both of the 0 or 28 keys, and the corresponding value for those duplicate rows is not the fully reduced count. In my test, the results were: [{"key":0,"value":2},{"key":28,"value":1},{"key":0,"value":1},{"key":74,"value":1},{"key":28,"value":1}]

The workaround to this bug is to ensure that the list of keys passed to the query is in ascending order; but this is not a documented or intuitive restriction. It is also unclear whether a strict ordering is always achievable for certain lists of keys, though in our actual usage the values in the key lists are of uniform type and have a well-defined ordering.