The migration cloner abort sequence does not transmit or validate the migration session id. Because of this it is possible that one shard aborts migration, which has been started by a completely different donor shard.

This bug is exacerbated in 3.3 because failure to execute the _recvChunkStart command is always followed-up by an abort. That way if two migrations with different donors, but the same recipient have the potential of conflicting with each other in which case one of the migrations will remain stuck.