[SERVER-47915] Write commands silently ignore readConcern via mongos Created: 04/May/20  Updated: 18/Oct/21  Resolved: 18/Oct/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Jonathan Lee
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-58176 Mongos does not validate readConcern ... Closed
Related
related to SERVER-60765 Complete TODO listed in SERVER-47915 Closed
is related to SERVER-47690 mongos changes for snapshot reads Closed
Operating System: ALL
Sprint: Repl 2020-06-01
Participants:

 Description   

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.



 Comments   
Comment by A. Jesse Jiryu Davis [ 13/May/20 ]

Add tests in jstests/noPassthrough/readConcern_snapshot_mongos.js.

Generated at Thu Feb 08 05:15:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.