function assertSortOrderWithCollationIndexBF17891() { const coll = db.bf17891; coll.drop(); assert .commandWorked(db.createCollection(coll.getName())); // Create an index with a non-simple collation. assert .commandWorked( coll.createIndex({a: 1, b: 1}, {collation: {locale: "en_US" , strength: 1}})); // Insert some documents into the collection. The value of 'a' is the same non-string value for // each document, while 'b' is a string. assert .commandWorked( coll.insert([{a: 0, b: "ccc" }, {a: 0, b: "ddd" }, {a: 0, b: "CCC" }, {a: 0, b: "DDD" }])); // Run a point-query on the first field of the compound index with a sort on the second field. const indexSortedResults = coll.find({a: 0}, {_id: 0}).sort({b: 1}).toArray(); // Repeat the query but this time force a COLLSCAN. const collScanSortedResults = coll.find({a: 0}, {_id: 0}).sort({b: 1}).hint({$natural: 1}).toArray(); // Print out the explain results for this query. It will be observed that the plan is a // SORT_MERGE-IXSCAN using the {a: 1, b: 1} index, despite the fact that this index has a // non-simple collation. The {a: 1, b: 1} index is eligible to answer the query because the // predicate 'a' is a non-string value. We then run through some checks to see whether we can // avoid performing an in-memory sort, eventually calling QueryPlannerAnalysis::explodeForSort. // But this method fails to notice that the index's collation should make it ineligible to // provide a sort for this query, and so we end up producing a SORT_MERGE plan that will // incorrectly sort the output according to the collation. printjson(coll.find({a: 0}).sort({b: 1}).explain()); // The documents should be returned in ascending order, but instead are sorted according to the // case -insensitive index. The COLLSCAN produces the correct ordering of results. assert .docEq(indexSortedResults, collScanSortedResults); }