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

UUID -> NSS resolution may fail after moveCollection / other sharding migrations

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Catalog and Routing
    • ALL
    • CAR Team 2024-07-22, CAR Team 2024-08-05, CAR Team 2024-08-19, CAR Team 2024-09-02, CAR Team 2024-09-16
    • 200

      It's possible for lookupNSSbyUUID to fail to find a collection's NSS from its UUID on the donor after a moveCollection .

      Example 1:
      This breaks the AutoGetCollection* helpers. AutoGetCollection* accept a NamespaceStringOrUUID, and so when a UUID is provided, the first step is to resolve the UUID to a NSS so that the lock can be grabbed.

      Essentially because UUID -> NSS resolution can fail, what should've been a StaleConfig (or other sharding staleness error) due to the moveCollection will now manifest as a NamespaceNotFound because we were unable to find the UUID, which is incorrect.

      There may be other cases besides AutoGetCollection* where the existing behavior is problematic. See comments and linked BF / tickets for more info and examples. The examples listed below are not exhaustive.

        1. move_unshard_collection_while_building_index.js
          4 kB
        2. reshard_collection_while_building_index.js
          5 kB
        3. reshard_while_building_indexes.js
          4 kB

            Assignee:
            antonio.fuschetto@mongodb.com Antonio Fuschetto
            Reporter:
            vishnu.kaushik@mongodb.com Vishnu Kaushik
            Votes:
            0 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated:
              Resolved: