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

CurOp index build collection scan message inconsistent with listIndexes build info

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Storage Execution
    • Fully Compatible
    • ALL
    • v8.0
    • Execution Team 2024-04-29, Execution Team 2024-05-13
    • 20

      The index build process updates both the currentOp message and the listIndexes results to reflect the current phase of the index build. For the collection scan phase, the gap between updating the currentOp message and setting the phase for listIndexes (and resumable index builds) may be noticeable enough on slow machines for the two command results to be inconsistent with each other.

      We have observed occasional failures in our CI system as a result of this issue in the test list_indexes_index_build_info.js, where the test helper IndexBuildTest.waitForIndexBuildToScanCollection() infers the collection scan state from the initialization of the progress meter in the currentOp output.

      Besides listIndexes, the index build phase is used to support[ resuming index builds|https://www.mongodb.com/docs/manual/core/index-creation/#monitor-in-progress-index-builds] that have been interrupted by server shutdown. We save the information in MultiIndexBlock::_constructStateObject() and parse it on startup in StorageEngineImpl::_handleInternalIdent(). The handling of the resumable index build info should be a consideration in any potential solution.

      We should also revisit IndexBuildTest.waitForIndexBuildToScanCollection() to see if it can be made more robust by checking the listIndexes output before getting the operation ID.

            Assignee:
            benety.goh@mongodb.com Benety Goh
            Reporter:
            benety.goh@mongodb.com Benety Goh
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: