When working on SERVER-127609, I noticed rare flaky test failures in the no_passthrough_execution_control_with_prioritization suite where the join_path_arrayness_invalidation.js test was failing at a rate of ~1/240 due to join opt not being used.

The test sets internalQueryExecYieldIterations: 1 which means the sampling queries yield after every unit of work. The :no_passthrough_execution_control_with_prioritization suite enables executionControlDeprioritizationGate: true which in conjunction with the always-on executionControlHeuristicDeprioritization, mean that CBR sampling queries get routed to the low-priority ticket pool after 3 ticket acquisitions due to the large number of yields. An op gets deprioritized if it has yield enough times (by default 3) which we hit given that we yield after very doc.

The exact throw site (what exception fires on evergreen) is still unknown. The test has been tagged incompatible_with_execution_control_with_prioritization as a short-term fix. However, due to this unknown exception being thrown, we end up falling back to the non-join code path and assertions that except the join code path to be used end up failing.

We should investigate why this spurious failure happens under this interaction in join. We should also consider writing a regression test to ensure that failures in sampling queries results in a graceful fallback to the non-join opt code path.