From david.percy@mongodb.com :

On a clustered collection, if you hint {$natural: -1} and sort {_id: 1} in opposite directions, then we're wrongly assuming the clustered scan satisfies the sort:

> db.clustered_collection.find().sort({_id:1}).hint({$natural: -1})
{ "_id" : 3, "a" : 3 }
{ "_id" : 2, "a" : 2 }
{ "_id" : 1, "a" : 1 } 

A similar query that sorts on {a: 1} gets the right answer, with a blocking sort:

> db.clustered_collection.find().sort({a:1}).hint({$natural: -1})
{ "_id" : 1, "a" : 1 }
{ "_id" : 2, "a" : 2 }
{ "_id" : 3, "a" : 3 } 

And a normal collection gets the right answer, with a blocking sort:

> db.normal_collection.find().sort({_id: 1}).hint({$natural: -1})
{ "_id" : 1, "a" : 1 }
{ "_id" : 2, "a" : 2 }
{ "_id" : 3, "a" : 3 } 

It appears that there are multiple issues contributing to this:

• CollectionScanNode::computeProperties doesn't take scan direction into account when computing which sort it provides on a clustered collection, so it will claim to provide an ascending sort even when it is a backwards scan.
• Even when the scan's sort is properly computed, the planner will still think that the sort can be provided if we reverse the scan here. However reverseScans won't actually reverse the scan at this point because reverseCollscans defaults to false.