In presence of more than one ready range deletion referring ranges containing more than rangeDeleterBatchSize documents, the range-deleter is currently working in a round-robin fashion.

Example with ready range deletions task documents A and B:

• Pick A's range, delete batch according to rangeDeleterBatchSize, re-enqueue for deletion
• Pick B's range, delete batch according to rangeDeleterBatchSize, re-enqueue for deletion
• Pick A's range, delete batch according to rangeDeleterBatchSize, re-enqueue for deletion
• ...continue until orphan documents in ranges have to be cleared up...

As a result, users may incur into some issues such as:

• The balancer may get blocked trying to move back some range on the old donor.
• With sufficiently fast migrations, the time for a range deletion task to complete increases exponentially. (The more ranges get enqueued, the less is probable for a range to be chosen for deletion).

SERVER-61637 increased the batch default size to MAX_INT in order to work around this issue, but the problem still stands in case the parameter is set to a lower value. SERVER-47699 pretty much removed the need for batching, but there are some scenarios in which it may still be needed to decrease the batch size (e.g. if a machine is under very intense user CRUD load).

Objective of this ticket is making sure that once a batch from a range has been deleted, the next round will keep on deleting the same range.

One solution could be to loop within the deletion task as long as the number of deleted documents for the range is greater than zero.