It is possible for a secondary which becomes the new primary to already have the latest shard version for the collection being resharded due to already having refreshed the sharded collection as a secondary earlier. Failing to call onReshardingFieldsChanges() on the new primary is data loss (in the case of a new donor shard primary which fails to install the critical section) or stalls the resharding operation (in the case of a new shard primary which doesn't ever fulfill a mongo::Promise).

Chunk migration addresses this type of issue by clearing the filtering metadata and triggering a call to onShardVersionMismatch() while the new primary is still in drain mode. Resharding take the following steps, as taken from chunk migration.

• Synchronously clear the filtering data on the resharding collections.
• Asynchronously call onShardVersionMismatch on each resharding collection run on some non-migration specific task executor.