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

check if addShardHandle present in ShardingCatalogManagerImpl::_handleAddShardTaskResponse before continuing

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.4.0-rc0
    • Fix Version/s: 3.4.0-rc1
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Sharding 2016-10-31
    • Linked BF Score:
      0

      Description

      If removeShard() is called for the shardId, the CallbackHandle for the task to upsert the shardIdentity on the new shard is canceled, and the CallbackHandle for that task is untracked:

      https://github.com/mongodb/mongo/blob/r3.4.0-rc0/src/mongo/s/catalog/sharding_catalog_manager_impl.cpp#L1683-L1693

      Since canceling the task can occur after the task has already completed, but before the task's callback has run, it's possible for the task to have been canceled but not receive the CallbackCanceled status, which currently is checked for in the callback:

      https://github.com/mongodb/mongo/blob/r3.4.0-rc0/src/mongo/s/catalog/sharding_catalog_manager_impl.cpp#L1771-L1774

      In this case, we don't return early, and end up trying to untrack the handle again, which hits an invariant (BF-3721).

      To fix this, we should also return early if the handle is no longer tracked (signifying the shard has been removed).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              esha.maharishi Esha Maharishi
              Reporter:
              esha.maharishi Esha Maharishi
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: