When multiplanning, the server will fail an entire query if a candidate plans fails during the evaluation period. This may make sense for cases like a collection drop, but for something like an index drop (or hiding an index) then it could be reasonable to replan the query from scratch instead of failing.

This can happen fairly easily if a user wants to clean up any unused indexes, which would typically be done by inspecting the results of $indexStats. However this approach can be misleading because $indexStats will not show queries which used (or are using) the index for plan selection, but ultimately do not end up using the index for the winning plan.

There is an existing concurrency test that demonstrates similar behavior to what this ticket describes, however there doesn't necessarily need to be a replan or cached plan involved.