[SERVER-70744] [CQF] Investigate repeated optimization failure during runMemoPhysicalRewrite Created: 20/Oct/22  Updated: 21/Oct/22  Resolved: 21/Oct/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Hana Pearlman Assignee: Svilen Mihaylov (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-70770 [CQF] Fix requirement on rid for non-... Closed
Sprint: QO 2022-10-31
Participants:

 Description   

This was seen while trying to enable the CQF FF for the no_passthrough suite. For example, the following will exit uncleanly due to the tassert:

buildscripts/resmoke.py run --suite=no_passthrough --mongodSetParameter=“{featureFlagCommonQueryFramework: true}” jstests/noPassthrough/change_streams_required_privileges.js

I see similar failures for jstests/noPassthrough/set_user_write_block_mode.js and enterprise/jstests/live_import/export_collection_command_sanity.js as well.

Here is an example of the logs indicating the failure. The logs show repeated instances of the “Optimization failed” tassert, though all of the involved queries seem very similar, probably indicating a single issue. Upping the log level shows a translated ABT that looks something like this:

Root []
|   |   projections: 
|   |       scan_0
|   RefBlock: 
|       Variable [scan_0]
Filter []
|   EvalFilter []
|   |   Variable [scan_0]
|   PathConstant [] Const [true]
Scan [system.users_a71c6c99-f3e4-4124-9cc7-651cbadc4a20]
    BindBlock:
        [scan_0]
            Source []

A pretty straightforward query, possibly except for the fact that it references a system collection. It’s possible that these queries represent something out of scope for MS2 that we are missing from the fallback. But, interestingly, sampling CE completes successfully. So I think there may be something going wrong during optimization.


Generated at Thu Feb 08 06:17:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.