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

$lookup sequential cache can incorrectly treat a $facet as non-correlated

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.0.1, 4.4.16, 5.0.11
    • Affects Version/s: 4.4.13, 5.0.7, 4.2.20, 6.0.0-rc6
    • Component/s: None
    • Labels:
    • Fully Compatible
    • ALL
    • v5.3, v5.0, v4.4
    • QO 2022-05-16, QO 2022-05-30, QO 2022-06-13, QO 2022-06-27, QO 2022-07-11, QO 2022-07-25, QO 2022-08-08
    • 135

      For a pipeline of the following shape:

      [{$lookup: {let: {a: ...}, pipeline: [{$facet: {array: [{$redact: {...$$a...}}]}}]}]

      We can get incorrect results with optimizations enabled if the following occurs:

      1. $lookup creates the sequential cache and slaps it at the end of the sub-pipeline
      2. $lookup then attempts to re-order the cache to the optimal position with a non-correlated prefix. It relies on the dependency tracker to achieve this.
      3. The $facet within the $lookup reports it's dependencies, (incorrectly?) indicating that it does not depend on any of the let variables even though it has a sub-pipeline which refers to $$a. This happens because the $redact stage within the $facet does not support dep tracking, so the variable reference is not found.
      4. The cache does not swap with the facet since it believes it to be non-correlated, which can lead to incorrect query results.

      Note that in step 3, if a stage within the $facet is "not supported" for dep analysis, it is not propagated back to the facet but instead ends up setting the needWholeDocument flag.

            nicholas.zolnierz@mongodb.com Nicholas Zolnierz
            nicholas.zolnierz@mongodb.com Nicholas Zolnierz
            0 Vote for this issue
            6 Start watching this issue