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

Write commands silently ignore readConcern via mongos

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • Labels:
      None
    • ALL
    • Repl 2020-06-01

      An insert/update/delete command should not accept readConcern, unless it is the first command of a multi-document transaction. mongod enforces this rule correctly:

      __unknown_name__-rs0:PRIMARY> db.runCommand({insert: "c", documents: [{}], readConcern: {level: "majority"}})
      {
              "operationTime" : Timestamp(1588595408, 2),
              "ok" : 0,
              "errmsg" : "Command insert does not support { readConcern: { level: \"majority\", provenance: \"clientSupplied\" } } :: caused by :: read concern not supported",
              "code" : 72,
              "codeName" : "InvalidOptions"
      }
      

      But mongos does not:

      mongos> db.runCommand({insert: "c", documents: [{}], readConcern: {level: "majority"}})
      {
              "n" : 1,
              "ok" : 1
      }
      

      mongos correctly bans snapshot readConcern for all commands outside multi-document transactions, but I will remove that check in SERVER-47690.

      Thus we have an old bug (write commands accept non-snapshot readConcerns on mongos) and a new one (write commands also accept snapshot readConcern on mongos).

      A comment on BasicCommandWithReplyBuilderInterface::supportsReadConcern claims:

      Note that this is never called on mongos. Sharded commands are responsible for forwarding the option to the shards as needed. We rely on the shards to fail the commands in the cases where it isn't supported.

      This doesn't work for write commands; I believe it's because mongos silently strips the readConcern from write commands in the process of constructing BatchWriteOp objects, and thus doesn't forward write commands' readConcerns to the shards. I don't know if the right solution is a) forward write commands' readConcerns to shards, b) ban readConcern for write commands (except as first transaction command) in mongos, c) something else.

      This change risks breaking compatibility: a client that connects only to mongos, not mongod, can set readConcern on write commands today and receive no error. (The readConcern is ignored.) I think this is low risk; such a client is incorrect and should receive an error. Anyway, it's unlikely anyone is making a mistake, since app devs use drivers instead of hand-writing commands.

            Assignee:
            jonathan.lee@mongodb.com Jonathan Lee
            Reporter:
            jesse@mongodb.com A. Jesse Jiryu Davis
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: