Currently there is this logic in SBE cached solution planner which seems suspicious as it's not quite obvious when a QueryPlanner could produce a single solution during replanning. The thinking is, if we get into the replanning logic, then we know that the cached plan has been picked up from multiple solutions, and since nothing has changed in the catalog meanwhile (otherwise the cached plan would have been invalidated and we would never pass through the cached solution planner) then the QueryPlanner should still produce multiple solutions during replanning.

david.storch suggested that in order to get into you would have to pick up a different view of the catalog in between making the decision to replan and calling QueryPlanner::plan() as part of the replanning operation. This seems potentially possible given that we can yield during the cached plan trial period, but a new catalog view could only be available after a write operation which changes a catalog object, so we should be able detect it during plan execution and error out. In any case, we need to verify this hypothesis and if this scenario is impossible replace the aforementioned code block with MONGO_UNREACHABLE_TASSERT.