The upgrade procedure creates range deletion task documents in the following way: for each local collection, refresh the routing table and - if sharded - create range deletion task documents for all non-owned ranges.

This procedure does not take into account that no range deletion must happen if the local collection uuid is not matching with the uuid tracked by the config server. This may happen, for example, when a shard holds a stale incarnation of a collection due to SERVER-17397.

Detailed flow

Since v4.2 is not tracking orphans on disk, submitOrphanRangesForCleanup is invoked by every shard in order to create range deletion tasks in the following way:

• for each database
  • for each collection (found in the LOCAL catalog)
    • call submitOrphanRanges, that does the following:
      • Get from the config server the routing table
      • if the collection is unsharded --> do nothing
      • else for each chunk not-owned by the current shard
        • Create a range deletion task
        • Persist the range deletion task document

The problem lies in how a range deletion task document is created: the uuid from the local catalog is persisted rather than the one known by the config server.