After the first collection lock acquisition, the CollectionRangeDeleter's asynchronous thread validates that it is operating on the same collection it was scheduled with.

However, later on it drops the collection lock in order to wait for majority replication/range deleter throttling and when it reacquires it back after the blocking wait completes, it doesn't re-check whether the collection is still the same and proceeds to directly modify the metadata manager state which might be for a completely different collection now.