Migration starts on current primary node P0 of the donor shard. Commit of the migration fail due to network error _cleanup() is executed and  as part of it endMetadataOp() will persist the latest config time. This is useless since we still don't have knowledge of the config time that is inclusive of the migration commit. Asynchronous recovery of the migration is spawned During recovery we read again from the config server and we realized that actually the commit succeed We will call completeMigration() and we will persist the migration decision in the coordinator document without calling endMetadataOp() . Stepdown will happen before removing the coordinator document. A new primary node P1 of the donor shard will be elected and it will try to recover the migration again since the coordinator document is still present. This time it will find that the migration decision have been already set as kCommitted and it will call again completeMigration() without calling endMetadataOp() Since the configOpTime known to P1 is not inclusive of the latest committed migration, there is no guarantee that any subsequent refresh of the filtering metadata would include the committed migration.