[DRIVERS-569] Update handling of write concern errors by user management commands Created: 12/Sep/18  Updated: 13/Apr/22

Status: Implementing
Project: Drivers
Component/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Gregory McKeon (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on CDRIVER-2900 Update handling of write concern erro... Backlog
depends on CXX-1703 Update handling of write concern erro... Blocked
depends on CSHARP-2451 Update handling of write concern erro... Closed
depends on GODRIVER-689 Update handling of write concern erro... Closed
depends on JAVA-3120 Update handling of write concern erro... Closed
depends on MOTOR-293 Update handling of write concern erro... Closed
depends on NODE-1792 Update handling of write concern erro... Closed
depends on PHPC-1304 Update handling of write concern erro... Closed
depends on PYTHON-1703 Update handling of write concern erro... Closed
depends on RUBY-1613 Update handling of write concern erro... Closed
depends on SERVER-28871 Remove write concern error backwards ... Closed
Server Compat: 4.1
Driver Compliance:
Key Status/Resolution FixVersion
NODE-1792 Fixed 3.2.0
SCALA-482 Done
PYTHON-1703 Won't Fix
CSHARP-2451 Won't Fix
PERL-1047 Won't Fix
RUBY-1613 Fixed 2.19.0
JAVA-3120 Won't Fix
CXX-1703 Blocked
PHPC-1304 Won't Fix
MOTOR-293 Works as Designed
GODRIVER-689 Done
CDRIVER-2900 Backlog

 Description   

All commands that write can accept write concern should have a standard way of reporting write concern errors. When a command succeeds but fails waiting for write concern, the command response indicates ok:1, but has a writeConcernError field. User management commands, however, report errors differently - a failed write concern for them causes the whole command to report ok:0.

Drivers need to update handling of write concern errors by user management commands to be the same as any other command.



 Comments   
Comment by Shane Harvey [ 07/Dec/18 ]

Here's a concrete example on MongoDB 4.0.4:

MongoDB Enterprise 3de4d42f-b25b-49d6-8997-1dd19e067fb7:PRIMARY> db.adminCommand({createUser:"foo2", pwd:"pwd", roles:["read"], writeConcern:{w:"majority", wtimeout:1}})
{
	"ok" : 0,
	"errmsg" : "waiting for replication timed out",
	"code" : 64,
	"codeName" : "WriteConcernFailed",
	"writeConcernError" : {
		"code" : 64,
		"codeName" : "WriteConcernFailed",
		"errmsg" : "waiting for replication timed out",
		"errInfo" : {
			"wtimeout" : true
		}
	}
}

To be consistent with other commands that report writeConcernError the output should be:

{
	"ok" : 1,
	"writeConcernError" : {
		"code" : 64,
		"codeName" : "WriteConcernFailed",
		"errmsg" : "waiting for replication timed out",
		"errInfo" : {
			"wtimeout" : true
		}
	}
}

Generated at Thu Feb 08 08:21:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.