[CDRIVER-3147] CodeNames for command errors not reported in reply of write operations Created: 22/May/19  Updated: 10/Feb/23

Status: Blocked
Project: C Driver
Component/s: libmongoc
Affects Version/s: None
Fix Version/s: None

Type: Bug 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:
Depends
is depended on by PHPC-1386 BulkWriteException and ExecutionTimeo... Blocked
is depended on by DRIVERS-478 Errors raised by drivers should inclu... Implementing
Related
is related to CDRIVER-2635 Errors raised by drivers should inclu... Closed
is related to CDRIVER-4425 Provide access to raw result document... Closed
is related to DRIVERS-478 Errors raised by drivers should inclu... Implementing
is related to CDRIVER-3422 Unified test format Closed
Epic Link: CDRIVER-4576

 Description   

According to this comment on CDRIVER-2635, the codeName for a given error should be available via the reply parameter of whatever functions that have it. However, write functions that fail do not report any error information in the reply.

e.g. the following code sample

mongoc_write_concern_set_w(wc, 100);
mongoc_write_concern_append(wc, options);
if (!mongoc_collection_insert_one(collection, insert, options, &reply, &error)) {
    printf("err inserting, reply: %s\n", bson_as_relaxed_extended_json(&reply, NULL));
    printf("err domain: %d code: %d message: %s\n", error.domain, error.code, error.message);
}

Fails and produces the following output:

err inserting, reply: { "insertedCount" : 0 }
err domain: 17 code: 2 message: cannot use 'w' > 1 when a host is not replicated

For reference, the shell does accurately report a "BadValue" codeName:

> db.mycoll.insertOne({}, {writeConcern: {w: 100}})
2019-05-24T15:55:21.234-0400 E QUERY    [js] WriteCommandError: cannot use 'w' > 1 when a host is not replicated :
WriteCommandError({
	"ok" : 0,
	"errmsg" : "cannot use 'w' > 1 when a host is not replicated",
	"code" : 2,
	"codeName" : "BadValue"
})



 Comments   
Comment by Jeremy Mikola [ 14/Nov/22 ]

kevin.albertson@mongodb.com: Linking this up with CDRIVER-4425, as I think that may address this and unblock the downstream language tickets.

On that note, do you think the approach in CDRIVER-4425 should be codified in the CRUD spec? If so, perhaps you could work with gil.alon@mongodb.com to implement DRIVERS-1547 in conjunction with the libmongoc work. I'd be happy to review anything.

Comment by Kevin Albertson [ 02/Feb/21 ]

Re-opening, pending spec changes to clarify how command errors should be returned in write operations (DRIVERS-1547).

Comment by Kevin Albertson [ 25/Jan/21 ]

PR: https://github.com/mongodb/mongo-c-driver/pull/728

Comment by Kevin Albertson [ 30/Nov/20 ]

Thank you for the heads up. libmongoc's transaction spec runner infers the code name from the code. I don't think we'll block the unified test runner on this (CDRIVER-3422), but it may make sense to schedule this sooner so we can get better feedback from the test runner.

Comment by Kaitlin Mahar [ 22/Nov/20 ]

Note: I just encountered this while implementing the unified test runner - kevin.albertson I expect you will encounter it as well, in particular on the test "remain pinned after non-transient Interrupted error on insertOne" from file "poc-transactions-mongos-pin-auto". (At least that's the first place I've run into it.)

It looks like we did encounter it as well while implementing the transactions runner, however due to the loose way in which we wrote code name matching (to allow either a matching code name or a missing code name) to account for SERVER-36755 we did not notice it.

Comment by Kevin Albertson [ 03/Jun/19 ]

Also worth considering how we report bulk write errors (e.g. if second command in batch fails, or there are multiple errors in an unordered bulk write, how do we report it?)

Comment by Patrick Freed [ 24/May/19 ]

I came across this when adding codeName to our error types, but it looks like we'll encounter the same issue when implementing the transactions spec test runner.

Comment by Jeremy Mikola [ 24/May/19 ]

patrick.freed: Did you come across this while trying to implement the errorCodeName assertion in the Transactions spec test runner? I believe I ran into the same roadblock with PHPLIB-365.

Generated at Wed Feb 07 21:17:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.