[SERVER-46598] Invalid custom write concern string should result in top-level command error Created: 03/Mar/20  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Participants:

 Description   

Commands can fail either with a "top-level error" (ok:0 with an error code and error message) or with a writeConcernError. The latter means that the writes were successfully applied locally, but the client's write concern has not been satisfied.

In the case that the writeConcern specification provided by the client is invalid, the server will fail with a top-level error, and will not perform any writes:

MongoDB Enterprise __unknown_name__:PRIMARY> db.c.insert({test: "one two"}, {writeConcern: 1})
Error: invalid parameter: expected an object (writeConcern) :
runClientFunctionWithRetries@src/mongo/shell/session.js:361:27
runCommand@src/mongo/shell/session.js:455:25
DB.prototype._runCommandImpl@src/mongo/shell/db.js:147:12
DB.prototype.runCommand@src/mongo/shell/db.js:162:16
DBCollection.prototype._dbCommand@src/mongo/shell/collection.js:171:16
executeBatch@src/mongo/shell/bulk_api.js:912:22
Bulk/this.execute@src/mongo/shell/bulk_api.js:1163:21
DBCollection.prototype.insert@src/mongo/shell/collection.js:317:22
@(shell):1:1
 
MongoDB Enterprise __unknown_name__:PRIMARY> db.c.find()
// No results.

In the specific case of an illegal custom write concern string in the w field, however, the writes will take place and the command will fail with a writeConcernError. Custom write concern can be used to request acknowledgement that writes have propagated to specific tagged nodes. As an example of the failure caused by an illegal custom write concern:

MongoDB Enterprise __unknown_name__:PRIMARY> db.c.insert({test: "one two"}, {writeConcern: {w: "invalid"}})
WriteResult({
	"nInserted" : 1,
	"writeConcernError" : {
		"code" : 79,
		"codeName" : "UnknownReplWriteConcern",
		"errmsg" : "No write concern mode named 'invalid' found in replica set configuration",
		"errInfo" : {
			"writeConcern" : {
				"w" : "invalid",
				"wtimeout" : 0,
				"provenance" : "clientSupplied"
			}
		}
	}
})
 
MongoDB Enterprise __unknown_name__:PRIMARY> db.c.find()
{ "_id" : ObjectId("5e5ed86edff28df350e4a8bb"), "test" : "one two" }

We should improve this behavior by making invalid custom write concern fail earlier. Instead of performing the writes and then failing with a writeConcernError, we should fail while parsing the command, before doing any writes. The UnknownReplWriteConcern error should also be returned as a top-level error rather than a writeConcernError.



 Comments   
Comment by Kevin Pulo [ 04/Mar/20 ]

Will this need some sharding consideration? Otherwise there's the risk that a write may happen on some shards but not others (since custom modes are currently defined per-shard). Whereas the current behaviour results in the write happening consistently across all shards, followed by write concern failure.

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