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

No-op invocations of setUserWriteBlockMode must await majority confirmation of SystemLastOpTime

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.2.0-rc0, 6.0.12, 7.0.4
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Server Security
    • Fully Compatible
    • ALL
    • v7.0, v6.0
    • Security 2023-10-16, Security 2023-10-30, Security 2023-11-13
    • 100

      If setUserWriteBlockMode changes a primary's user write block mode, it will issue a write to a system collection. If the primary's user write block mode disposition is unchanged, then the command is a no-op and no write is issued. Either way, the command doesn't know whether the rest of the replicaset agrees with the local state yet, and so will await majority confirmation of the active Client object's last written OpTime.

      Unfortunately, the no-op variant of the command does not advance the OpTime. If an election occurs after the OpTime is stored in the Client but before commit is awaited, waiting will fail with an error. It will not be possible to re-run the command on the same connection, because the OpTime is never advanced.

      Instead, if we find that we're eliding writes, we should advance the Client's OpTime using setLastOpToSystemLastOpTime

            spencer.jackson@mongodb.com Spencer Jackson
            spencer.jackson@mongodb.com Spencer Jackson
            0 Vote for this issue
            8 Start watching this issue