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

mongos generates a reply for writes sent by client with w:0

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.0.9, 8.1.0-rc0, 6.0.16, 8.0.0-rc3, 7.3.3
    • Affects Version/s: 7.0.0, 8.0.0-rc0, 8.1.0-rc0
    • Component/s: None
    • None
    • Catalog and Routing
    • Fully Compatible
    • ALL
    • v8.0, v7.3, v7.0, v6.0, v5.0
    • CAR Team 2024-04-15, CAR Team 2024-04-29

      SERVER-83193 introduced a behavioral change that I think is likely unintentional.

      In general, we seem to equate w:0 ("unacknowledged") writes with fire-and-forget writes (i.e. those with the moreToCome flag set on the OP_MSG request). The drivers spec requires that drivers send unacknowledged writes with the moreToCome flag, and the server test runner (aka legacy shell) will always send w:0 writes as fire-and-forget as well.

      Following from that, it stands to reason that the server should not actually generate a command response for any unacknowledged write because the response will never be consumed by a spec-compliant client.
      Accordingly, we have mongos logic that skips generating a reply for a write command if it was sent with w:0:

      mongos must "upgrade" w:0 write concerns when sending child requests to shards in order to see which writes succeed/fail. Previously, this was done by appending an upgraded WC directly to the child requests:

      In SERVER-83193, we started upgrading the write concerns for these commands by upgrading the opCtx write concern:

      This change means that the checks above that inspect the opCtx write concern when determining whether or not to generate a reply no longer work on mongos (since they observe the "upgraded" write concern) and we still generate a reply for a w:0 write that a spec-compliant client will never actually consume, doing unnecessary work. 

      Possibly, there could be other issues caused by this as well if we have any other code that relies on being able to inspect the original request's write concern, though I did not find any other instances in a quick search. 

      This issue was found via the Node driver which was erroneously sending w:0 writes without the moreToCome flag. (NODE-6060)

      Reproducer from neal.beeken@mongodb.com:

      db.runCommand({ update: 'test', updates: [ { q: { a: 1 }, u: { c: 'c' }, multi: true } ], writeConcern: { w: 0 }, ordered: true })
      

      Assuming this change was unintentional, we should correct it and should also add test(s) for this that cover all of insert, update, delete, bulkWrite since it seems we are missing them.

            Assignee:
            paolo.polato@mongodb.com Paolo Polato
            Reporter:
            kaitlin.mahar@mongodb.com Kaitlin Mahar
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: