With an upcoming change to the balancer we'll potentially abandon active migrations (and release their distlocks) on failover.

3.2 shards are fine, because they hold the distlock.

For 3.4 shards that expect the balancer to hold the distlock, they'll be running without the distlock. It will be possible for the following scenario to occur:

• the balancer releases the distlock because of an error during migrations recovery
• A drop occurs
• The collection is recreated and the chunk exists again.
• the balancer schedules another migration for the collection and reacquires the distlock
• the 3.4 shard tries to commit the migration.

Thus, the CommitChunkMigration command must also take a collection version parameter from the shard, and compare its epoch value to the config server’s collection version’s epoch. If they don’t match, fail the commit command.