We have observed occasionally failures in migration_fails_if_exists_in_rangedeletions.js due to host slowness.

The reason is that the 
receiveChunkWaitForRangeDeleterTimeoutMS has been increased only on shard1 (here) and not on shard0, which is the one that is actually performing the range deletion.
 
As a suggestion I would consider to update the receiveChunkWaitForRangeDeleterTimeoutMS on the suite configuration instead of doing it locally per every test. This solution has already been applied for other suites like sharding_auth_audit, concurrency_sharded_multi_stmt_txn_with_balancer, etc.

The suites affected on BF-25847 are sharding and sharding_opportunistic_secondary_targeting