[DRIVERS-2148] Crud spec claims only one of writeError/writeConcernError will be populated at a time Created: 06/Nov/19  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: CRUD
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Patrick Freed Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Driver Changes: Needed

 Description   

A comment above the definition of WriteException states the following:

/**
 * NOTE: Only one of writeConcernError or writeError will be populated at a time. Your driver must present the offending
 * error to the user.
 */

This isn't true, however. On a 3-node replica set, in a collection containing a document with _id: 1, the following command will produce both errors:

db.runCommand({
... insert: "test",
... documents: [ { _id: 1 }],
... writeConcern: {w: 100}
})

output:

{
	"n" : 0,
	"writeErrors" : [
		{
			"index" : 0,
			"code" : 11000,
			"keyPattern" : {
				"_id" : 1
			},
			"keyValue" : {
				"_id" : 1
			},
			"errmsg" : "E11000 duplicate key error collection: test.test index: _id_ dup key: { _id: 1.0 }"
		}
	],
	"ok" : 1,
	"writeConcernError" : {
		"code" : 100,
		"codeName" : "UnsatisfiableWriteConcern",
		"errmsg" : "Not enough data-bearing nodes"
	}
}

This direction may cause drivers to ignore the other error if they have already discovered one of them.

UnsatisfiableWriteConcern might be the only case in which this is possible, though.



 Comments   
Comment by Shane Harvey [ 16/Mar/20 ]

This ticket reminds me of another writeConcernError issue that we may want to document. The server can return the writeConcernError field on "ok:0" command errors too. A real example of this is when a transaction fails with NoSuchTransaction and the server waits for write concern which also happens to fail (SERVER-38850):

{ok: 0, code: 251, codeName: 'NoSuchTransaction', writeConcernError: {code: 91, codeName: "ShutdownInProgress"}}

Comment by Githook User [ 16/Mar/20 ]

Author:

{'username': 'egiurleo', 'name': 'Emily Giurleo', 'email': 'e.m.giurleo@gmail.com'}

Message: SPEC-1592 Allow hinting the delete command (#764)

  • fixed some small issues
  • fixed json tests
  • add tests for server error
  • added tests for client errors
  • iron out test versions
  • added tests for findOneAndDelete with hint
  • generate json files
  • moved tests to the correct folder and fixed version numbers
  • fix collection names and add some clarifying comments
  • added error tests for updateOne and updateMany
  • add more information to hint documentation
  • add json files
  • add tests for bulkWrite delete hints
Comment by Patrick Freed [ 17/Dec/19 ]

Your example does produce both errors, but an insert with multiple documents would map to an insertMany, which, according to the crud spec, throws a BulkWriteException and does allow for both errors to be specified.

It's really tricky to get this to happen without unsatisfiable write concern, since it would require the primary to error while performing the write and still attempt to replicate it. Alternatively, the write could succeed on the primary but fail on one secondary and timeout trying to replicate on another secondary. I think this could be achieved with failpoints, but I'm not sure if this scenario is any more likely than an unsatisfiable write concern.

Comment by Jeffrey Yemin [ 18/Nov/19 ]

Can you see if there is a more common way this could happen? Something like

db.runCommand({
... insert: "test",
... documents: [ { _id: 1},  { _id: 2},  { _id: 3}],
... unordered: true,
... writeConcern: {w: "majority", wtimeout: 1}
})

Where one of the documents is a duplicate, and the write concern also times out.

The other situation is a bulk, unordered write that is big enough to force a split, and where the first batch has a duplicate key error, and the second back a write concern error.

I'd love it if we could get a YML test for this, but it's a bit tricky

Comment by Rathi Gnanasekaran [ 18/Nov/19 ]

patrick.freed feel free to open a PR for this change.

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