[SERVER-39706] Include codeName field in writeErrors array Created: 21/Feb/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Oleg Pudeyev (Inactive) | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Optimization
|
||||||||
| Sprint: | Query 2019-06-17, Query 2019-07-01 | ||||||||
| Participants: | |||||||||
| Description |
|
Somewhere between v4.1.7-51-gb4f82034e6 and v4.1.8-73-ge2251dbc97, tests for the convenient transactions API started failing because the server ceased to return a code and code name for DuplicateKey errors. The response we are currently getting with 4.1.8:
It includes errmsg but no code or code name. 4.0 response for comparison:
It looks like previously DuplicateKey was returned as a top level error, and then it had code name and code, and now DuplicateKey is a write error and it does not have code name and code anymore. |
| Comments |
| Comment by Oleg Pudeyev (Inactive) [ 02/Jul/19 ] |
|
Per the discussion in slack, I think it is OK to not make any server changes and instead make this change to the spec test: |
| Comment by James Wahlin [ 24/Jun/19 ] |
|
Our proposal for addressing this ticket is to add 'codeName' as a field in the to the writeErrors array object, along side 'code'. We are waiting for clarification from the drivers team as to whether this would be an acceptable solution. |
| Comment by Craig Homa [ 06/May/19 ] |
|
james.wahlin will huddle up with redbeard0531 and drivers to see what the best next step for this is. |
| Comment by Mathias Stearn [ 18/Apr/19 ] |
|
I don't think we have ever included the codeName field in the writeErrors style reply used by write commands. For better or worse, that format has historically only had index, code, and errmsg fields. In the 4.0 output the error is reported as an {ok:0} style top-level command failure. The 4.1 reply is using the nested writeErrors form with {ok:1}. So code is being reported, just in a different format. Sending to Query to decide if the change in error reporting style is desirable, and if we want to start include codeName in writeErrors. |
| Comment by James Wahlin [ 21/Feb/19 ] |
|
CCing jeff.yemin & redbeard0531 who have been involved in discussion around error responses. |
| Comment by Oleg Pudeyev (Inactive) [ 21/Feb/19 ] |
|
The driver currently does not return error code name for errors affected by this ticket. In Ruby we parse the error code out of the message but do not do so for error code name (because the code name is not part of the message, and we don't have a map of all codes to code names in the driver). Therefore when these errors happen, the driver will not expose code name to users. This can be considered a regression from 4.0 and earlier 4.1 behavior. I am not clear on severity of not asserting the DuplicateKey error code name in the test suite, it is probably minor. For completeness, the workaround I am proposing for Ruby is to map 11000 to DuplicateKey and retain the assertion (https://github.com/mongodb/mongo-ruby-driver/pull/1267), though I made that PR prior to locating the spec PR mentioned above. |
| Comment by Kelsey Schubert [ 21/Feb/19 ] |
|
I believe the write error change was oleg.pudeyev, could you clarify whether this change in behavior is still a concern for you after applying the workaround? cc jesse, james.wahlin |
| Comment by Oleg Pudeyev (Inactive) [ 21/Feb/19 ] |
|
This was worked around in https://github.com/mongodb/specifications/pull/482 by removing the assertion that the code is a DuplicateKey. |