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

check if addShardHandle present in ShardingCatalogManagerImpl::_handleAddShardTaskResponse before continuing

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.4.0-rc1
    • Affects Version/s: 3.4.0-rc0
    • Component/s: Sharding
    • None
    • Fully Compatible
    • ALL
    • Sharding 2016-10-31
    • 0

      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).

            Assignee:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: