Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-74097

Sharded find with expected collection UUID does not handle all cases of concurrent DDL operations

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.0.0-rc0, 6.0.5, 6.3.0-rc1
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • v6.3, v6.0
    • Execution Team 2023-02-20, Execution Team 2023-03-06
    • 129

      When running a find command on a sharded collection with collectionUUID parameter, there is some special logic in the case where we don't target the primary shard but got a CollectionUUIDMismatch error without an actualCollection. In this case, we go to the primary shard in case the actualCollection is unsharded and thus only exists on that shard. The current logic expects that going to the primary shard will always throw an error (CollectionUUIDMismatch, StaleShardVersion, or StaleDbVersion), however it turns out this is not always the case and it is possible for no error to be thrown. Consider a concurrent collection drop on the collection that is being queried; it will executed in three steps:

      1. Remove entry from config.collections
      2. Perform local dropCollection on all non-primary shards
      3. Perform local dropCollection on the primary shard

      If we go to the primary shard between steps 2 and 3, that shard will still have the collection despite not getting a stale version error.

            Assignee:
            gregory.noma@mongodb.com Gregory Noma
            Reporter:
            gregory.noma@mongodb.com Gregory Noma
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: