Reproduction

The issue can be reproduced locally with unit test. The shard key pattern in the incident was {_userId: 1, type: 1, time: 1}.

To reproduce:

• Check out branch https://github.com/10gen/mongo/compare/master...chiihuang/AF-976_repro
• Run

  ninja build/install/bin/s_test && build/install/bin/s_test --filter AF976
  

Root Cause

The user's query requests sorting by

, resulting in an index bounds in backward direction. See a simplified query plan:

"winningPlan" : {
  "stage" : "LIMIT",
  "limitAmount" : 1,
  "inputStage" : {
    "stage" : "FETCH",
    "inputStage" : {
      "stage" : "SORT_MERGE",
      "sortPattern" : { "time" : -1 },
      "inputStages" : [
        {
          "stage" : "IXSCAN",
          "direction" : "backward",
          "indexBounds" : {
            "_userId" : [
              "[\"6ba576a-1139-407e-8f6b-11c3967c7fb2\", \"6ba576a-1139-407e-8f6b-11c3967c7fb2\"]"
            ],
            "type" : [
              "[\"cbg\", \"cbg\"]"
            ],
            "time" : [
              "[new Date(1665051622688), new Date(1664965222688)]"
            ]
          }
        },
        {
          "stage" : "IXSCAN",
          "direction" : "backward",
          "indexBounds" : {
            "_userId" : [
              "[\"6ba576a-1139-407e-8f6b-11c3967c7fb2\", \"6ba576a-1139-407e-8f6b-11c3967c7fb2\"]"
            ],
            "type" : [
              "[\"smbg\", \"smbg\"]"
            ],
            "time" : [
              "[new Date(1665051622688), new Date(1664965222688)]"
            ]
        }
       ]
    }
  }
}

collapseQuerySolution() assumes the IndexBounds is always ascending and attempts to unionize() them without forwardizing them. In a debug build, such a issue should have violated an invariant check in intersects() but not in a release build. So we only see this issue until it tripped the invariant check in unionize().

Plan of Attack

Forwardizing before unionizing them may address the bug. In the other call sites, the direction of index bounds evolves as below:

1. IndexBoundsBuilder builds IndexBounds in ascending direction
2. QueryPlannerAccess::finishLeadNode aligns IndexBounds with key pattern. The direction becomes forward. But it may have intervals in descending order.
3. QueryPlannerAccess::buildIndexedOr may reverse the direction to backward.

Since: a shard key pattern is always ascending, we may rely on the direction of a IXSCAN node to tell if we need to reverse the index bound in collapseQuerySolution.