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

reshardCollection command can return ReshardCollectionAborted instead of actual failure status code

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 5.0.0, 6.0.0, 7.0.0, 7.1.0-rc2
    • Component/s: None
    • None
    • Sharding NYC
    • ALL
    • 0

      If resharding fails due to any error that is not user initiated (and hence user won't expect ReshardCollectionAborted), followed by config server step down + step up, we recover the abort decision at the newly elected config server by checking the state document and signaling the context holder to abort here. When doing this we overwrite the status as ReshardCollectionAborted here incorrectly thinking it is user-initiated. Note that the original status at the previous config server primary's ReshardingCoordinatorService is present in memory in this onError handler in code.

      When checking if the context holder is aborted, we should additionally check if it was user-initiated and return the right status code.

            Assignee:
            backlog-server-sharding-nyc [DO NOT USE] Backlog - Sharding NYC
            Reporter:
            abdul.qadeer@mongodb.com Abdul Qadeer
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: