The CollectionRangeDeleter is currently extremely complex to reason about. Its main function is a static function that then calls back into a friend class (the MetadataManager) to access an instance of CollectionRangeDeleter, and it has to acquire and release locks to ensure the continued validity of the MetadataManager state as it processes a range. In addition, the logic for scheduling tasks is very complex and spread across a lot of code. It's all very brittle and making changes is extremely difficult.
We should refactor it so that:
1) The logic for looping over a batch of documents within a range is clear and consolidated
2) The logic for cleaning up a range does not rely on the MetadataManager
3) No collection locks are required except for doing the actual deletion of documents
4) The logic for scheduling a range for delayed deletion is simplified
5) The functionality is equivalent
- is depended on by
-
SERVER-43688 Race in range deleter can trigger invariant if epoch changes
- Closed
-
SERVER-45249 Make recipient wait for orphan cleanup before cloning indexes
- Closed