Cached plans with blocking SORTS will completely stop (close()) and restart (open()) after the first 101 documents have been processed by the sort stage. These documents are discarded, and the work done by the plan up to this point is wasted.

The strategy of aborting the plan mid-flight makes sense for multi-planning, when we want to run each plan for only a short duration to test its 'productivity'. However, for a plan already in the cache we should be "optimistic" about it remaining in the cache instead of paying the high cost of restarting the plan each time. Ideally, we'd have a solution which only aborts the query when it is clear that replanning is necessary.

The way this is implemented is that a 'resultsBudget' is set in the SBE runtime planner when all of the plans are blocking. In the case of a cached solution, there is only one candidate, and if it is blocking, the resultsBudget is set, causing it to stop after a certain number of results have been fed into the sort stage.