Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-56140

[SBE] UniqueStage::close() should clear its _seen buffer

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.0.0-rc0
    • Affects Version/s: None
    • Component/s: Query Execution
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Hide

      Run the attached repro script like so:

      python3 buildscripts/resmoke.py run --suites=jstestfuzz --additionalFeatureFlags=featureFlagSBE query_fuzzer_repro.js
      
      Show
      Run the attached repro script like so: python3 buildscripts/resmoke.py run --suites=jstestfuzz --additionalFeatureFlags=featureFlagSBE query_fuzzer_repro.js
    • Query Execution 2021-05-03

      We observed this failure here. I spent some time minimizing the repro so that it runs faster but didn't look into it deeply. See attached file query_fuzzer_repro.js

      The problematic find command is:

          {
              find: 'fuzzer_coll',
              filter: {'obj.obj.obj.array': {$exists: false}},
              projection: {'obj.obj.obj.num': 0},
              sort: {'obj.obj.obj.obj.obj.array': 1, _id: 1}
          },
      

      However, the fuzzer code will augment the projection with a $meta:"sortKey" expression. As a result, the find command runs in the classic engine, but the equivalent aggregate command runs using SBE. The find/classic version returns 102 documents whereas the agg/SBE version returns just 1. The following indexes exist on the collection, which I've found is necessary for the repro:

      const indexList = [
          {
              'obj.obj.obj.array': 1,
              'obj.obj.obj.obj.date': -1,
              'obj.obj.num': -1,
          },  // 15
          {
              'obj.obj.obj.array': 1,
              'obj.obj.num': -1,
          },  // 77
      ];
      

      It's possible that this is related in some way to SERVER-56132, since it looks like this failure also could involve early exit during SBE multi-planning.

            Assignee:
            mihai.andrei@mongodb.com Mihai Andrei
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: