MultiPlanStage::extractPlanExplainerData, used by CBR to pull out explain relevant information from a multiplanner if used in combination with CBR has this tassert:

tassert(11540200,
            "expected some plans to have been rejected before extracting their explain data",
            _rejected.size() > 0 || (hasBackupPlan() && _candidates.size() == 2));

This method is only called from within ranking.

Given this, MultiPlanStage, specifically as used by CBR, has an additional constraint that more than one solution must exist (possibly only if performing an explain query), as rejected solutions must exist.

Such hidden preconditions for some CBR strategies should be removed; MultiPlanner in general can handle single solutions fine (and indeed, is required to elsewhere in CBR).

This interdependence is tech debt that slows down ongoing CBR work and makes the codebase more fragile, and "happens" to pass only in particular configurations - this precondition is easy to violate when making unrelated changes. This can even be data dependent; strategies which mix multiplanning and CBR may pass when only one or the other is used, but hit this tassert if (for example) a different sample leads to combining multiplanning and CBR.

If removing is not practical, at the very least such preconditions should be enforced earlier in a visible manner, unconditionally. The more niche a particular behaviour comes by depending on unrelated conditions, the harder it becomes to have confidence it is guarded correctly by tests - especially if only jstests cover it.