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

v3.2 no-op applyOps doesn't wait for majority writeConcern before returning.

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.2.14
    • Affects Version/s: 3.2.9
    • Component/s: Sharding
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Sharding 2017-05-29, Sharding 2017-06-19
    • 0

      SERVER-24630 was introduced in v3.2.9 and made mongos/shard servers store the committed optime returned from commands to the config server, rather than the last seen optime.

      In the v3.2 shard applyOps command code we aren't properly waiting for majority write concern on no-ops / failures. This scope guard was wrapped around running applyOps on the server so that we would always update the last seen optime, regardless of applyOps results (SERVER-22933). But in v3.2, the waitForWriteConcern is done here in the same scope before the scope guard can fire. This wasn't a problem in v3.4 because the waitForWriteConcern code happened to get moved out of scope, so the scope guard is working correctly. The backport to v3.2, however, was not correct.

            Assignee:
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            Reporter:
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: