When we try to cleanup the MigrationSourceManager on error (cleanupOnError), we also clean up the MigrationChunkClonerSourceLegacy object (call cancelClone, which calls _cleanup), and then the MigrationChunkClonerSourceLegacy object is destructed. In the destructor, there's an invariant

invariant(!_deleteNotifyExec);

_deleteNotifyExec is a unique_ptr to a PlanExecutor object. In theory, in _cleanup(), it should be reset and destructed - hence the invariant. However, if an exception is thrown in _cleanup before this happens, and then ~MigrationChunkClonerSourceLegacy gets called, the program will abort since we're throwing an exception while already throwing an exception, which is A Bad Thing™. In the case of BF-8673 this seems to be what happened, presumably due to one of the functions in _cleanup failing due to shutdown being in progress. We could potentially fix this by wrapping these functions in a try-catch, or instead of using _deleteNotifyExec.reset() we could just std::move(_deleteNotifyExec) into the local scope so that _deleteNotifyExec will indeed be empty no matter what, and this invariant won't fail.