This is a bug in the implementation of yielding during SBE runtime planning. Yielding during SBE runtime planning was implemented under related ticket SERVER-48555. See "Steps To Reproduce" for a reliable way to provoke the bug.
The problem is as follows. When any of the candidate QuerySolutionNode trees is converted into a corresponding SBE execution plan, that plan is registered for yielding with the PlanYieldPolicySBE. At this point, however, the SBE tree has not yet been attached the OperationContext with a call to attachFromOperationContext().
Once all the SBE plans are actually constructed, we call sbe::MultiPlanner::plan() in order to choose the winning plan. This involves executing the candidate plans, and of course the first step in doing so is to prepare and open the plans. Each candidate is prepared and opened one-by-one.
The trouble is that we only attach the OperationContext to the plan immediately before opening it. Let's say that there are two candidate plans. We have attached the first to the OperationContext and are in the process of opening it. The second plan remains unattached and unopened. If a yield occurs during the open of the first candidate plan, then we attempt to save and restore each of the two candidate plans since both are registered for yielding. However, this invariant fails for the second (unattached) candidate plan because it expects the index scan stage to be attached to the OperationContext prior to yielding.
- is duplicated by
-
SERVER-52959 Fix invariant failure in IndexScanStage::doRestoreState()
- Closed
- is related to
-
SERVER-48555 SBE runtime planners should be able to yield during plan selection
- Closed