The CollectionShardingRuntime for a sharded collection is keeping a reference to a MetadataManager that is responsible to keep track of a list of open cursors to know how many queries are running using different filtering metadata for the collection at different points in time.

On a shard primary node, such list is iterated when having to schedule a range deletion task in order to determine whether it is needed to wait for running queries or the task can be "safely" scheduled after orphanCleanupDelaySecs because there are no queries acting on the orphan range.

However, when filtering metadata are cleared up, the CollectionShardingRuntime is loosing track of previous metadata managers. This means that the range-deleter may not honor the promise that all running queries on the shard primary have been completed before starting deleting documents from an orphaned range.

It follows that the following claim from the documentation has always been incorrect: "Before deleting the chunk during chunk migration, MongoDB waits for orphanCleanupDelaySecs or for in-progress queries involving the chunk to complete on the shard primary, whichever is longer".

This bug can be traced back to v5.0.