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

find by UUID can return NamespaceNotFound for a collection that is concurrently renamed

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.0.0-rc5, 4.1.1
    • Affects Version/s: None
    • Component/s: Storage
    • Labels:
      None
    • Fully Compatible
    • ALL
    • v4.0
    • Storage NYC 2018-05-21, Storage NYC 2018-06-04, Storage NYC 2018-06-18
    • 63

      The find command (and presumably any other command that needs to resolve UUIDs to namespaces), can return a NamespaceNotFound error on a collection that is concurrently renamed within the same database. If we try to execute a find command by UUID for a collection that exists but is being concurrently renamed, there is a race condition due to the fact that the find command resolves UUIDs to namespaces outside of its locks. For example, consider the following execution for a find and renameCollection command running on separate threads:

      Although accesses to the UUIDCatalog are made atomic by the catalog lock, different commands may still interleave their operations on the catalog in an arbitrary order, if not protected by stronger (database or collection level) locks.

      Attached is a repro (find_by_uuid_and_rename.js) demonstrating this issue. The race condition appears to be very narrow. Its probability is increased by adding a short sleep immediately after this line. Adding a mongo::sleepmillis(50) seemed sufficient.

        1. find_by_uuid_and_rename.js
          1 kB
          William Schultz

            Assignee:
            maria.vankeulen@mongodb.com Maria van Keulen
            Reporter:
            william.schultz@mongodb.com William Schultz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: