ISSUE SUMMARY
Given a query with an $or operator where:

1. one of the $or clauses includes a regex, $mod, $type, $elemMatch, $exists, geo, or range predicate with a non-simple type (like {a: {$gt: {b: 3}}}), and
2. that predicate has an index which it can use,

then the query may miss results from one of the $or clauses. For example:

db.foo.ensureIndex({name : 1})
db.foo.insert({_id : 1, name : "Alice"})
db.foo.insert({_id : 2, name : "Bob"})
db.foo.find({$or : [{name : /^(B|C)/}, {name : "Alice"}]})
{ "_id" : 2, "name" : "Bob" }

USER IMPACT
Significant user impact: query results may be incomplete.

WORKAROUNDS
One workaround is to use the $natural operator to force a collection scan, which may have a significant performance impact:

db.foo.find({$or : [{name : /^(B|^C)/}, {name : "Alice"}]}).hint({$natural : 1})
{ "_id" : 1, "name" : "Alice" }
{ "_id" : 2, "name" : "Bob" }

If query rewrite is possible, using the $in operator provides another workaround:

db.foo.find({name : {$in : [/^(B|^C)/, "Alice"]}})
{ "_id" : 1, "name" : "Alice" }
{ "_id" : 2, "name" : "Bob" }

AFFECTED VERSIONS
MongoDB production releases 2.6.0 and 2.6.1 are affected by this issue.

FIX VERSION
The fix is included in the 2.6.2 production release.

RESOLUTION DETAILS
The issue stems from an incorrect filter being affixed to FETCH and IXSCAN query solution nodes, which would filter the result set too narrowly. When an $or clause has inexact bounds, we must filter the results after performing the index scan. The filter should be an $or of all the predicates assigned to the corresponding index. The fix was to ensure that the filter includes all necessary predicates.