Note: this bug affects the release configuration of 7.0. The bug is also present in 8.0 and master, but only when --featureFlagSbeFull is enabled, which is not the release configuration.

See the attached repro-plan-cache.jsand inline comments for reproduction steps.

The problem can occur when:

• SBE plan cache is enabled
• Partial index
• Aggregation with $match with rooted $or and SBE-eligible group

The problem is that we encode a partial index discriminator into the plan cache key as a global discriminator (applying to the query as a whole), yet when we perform access path selection via the subplanner, we can use a partial index which the discriminator indicated was not eligible. This results in an entry in the SBE plan cache which has a hash that query shapes that are and are not eligible for the partial index hash to. This leads to incorrect results.

The reason that the classic plan cache doesn't suffer from this problem is that the subplanner caches index tags for each branch of the rooted $or separately. For a single branch, the discriminators for partial indexes work as expected.