[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: |
|
||||
| Driver Changes: | Needed | ||||
| Description |
|
A comment above the definition of WriteException states the following:
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:
output:
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 (
| ||||||
| 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)
| ||||||
| 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
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. |