Currently, the "idempotency" of restoreRangeDeletionTasksForRename is achieved by deleting previously "renamed" range deletion tasks and reschedule them with new migration ids. By doing so, the persistent state is clean but duplicate tasks are not unscheduled from the migration util executor.

A better strategy would be to assign migrations id to snapshotted range deletions at an early stage and afterwards simply check if the task has been already scheduled for the target collection.