As seen in https://jira.mongodb.org/browse/BF-30264 – it is possible that while resharding is in progress, a recipient primary may step down and the step up process does not wait for the step down to complete. When resharding completes on the recipient, the recipient state document is deleted on the current primary and this deletion is then replicated on the secondaries. Since an earlier secondary was a primary, it has a stale ActiveInstance (because the step up did not wait for the step down to complete), its deletion of the state document triggers the instance's cleanup and that is when the invariant failure is hit because the task in the GuaranteedExecutor failed to run before deletion. To avoid such scenarios, ReshardingDataReplication must join the ReshardingOplogFetcher thread pool.