[SERVER-34180] Add more information to WriteConflict error message Created: 28/Mar/18 Updated: 29/Oct/23 Resolved: 04/Sep/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Shane Harvey | Assignee: | Maria van Keulen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||
| Sprint: | Execution Team 2019-09-09 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
A WriteConflict error message provides very little information to the user:
It would be helpful to have a more detailed error message than just "WriteConflict". For example, we could change it to "Write conflict error: this operation conflicted with another operation, retry your multi-document transaction". CC: pasette |
| Comments |
| Comment by Githook User [ 04/Sep/19 ] |
|
Author: {'username': 'mvankeulen94', 'email': 'maria.vankeulen@mongodb.com', 'name': 'Maria van Keulen'}Message: |
| Comment by Maria van Keulen [ 04/Sep/19 ] |
|
I've updated the ticket description to capture the implementation plan discussed in the comment thread. |
| Comment by Eric Milkie [ 03/Apr/19 ] |
|
Good idea, we should do that. I'll update the ticket description. |
| Comment by Shane Harvey [ 22/Mar/19 ] |
|
Thanks for the explanation milkie I think that makes sense. Could we at least consider improving the error message to something more informative than justĀ "WriteConflict"? Maybe something akin to: "Write conflict error: this operation conflicted with another operation, retry your multi-document transaction". |
| Comment by Eric Milkie [ 06/Apr/18 ] |
|
I believe the difference is that in your example, duplicate key errors occur on static data, and thus the programmer could conceivably use the extra error data to fix or avoid the issue. |
| Comment by Shane Harvey [ 06/Apr/18 ] |
|
> The command, txnNumber, and stmtId should be knowable by the request that was sent that generated the WriteConflict. This is true for single-writes but drivers will raise the WriteConflict error as an exception. That exception might be caught at a point where the original operation is no longer accessible. Even so, any information as to why the write conflict occurred could be useful to the developer. We already have a precedent for doing this, for example duplicate key errors include the duplicated key in the error message. For bulk write commands the situation is worse. WriteConflict error is returned without even indicating which particular operation in the batch failed. |
| Comment by Ian Whalen (Inactive) [ 06/Apr/18 ] |
|
shane.harvey could you elaborate on what information would be actionable for users? Marking as Backlog for now. |
| Comment by Spencer Brody (Inactive) [ 28/Mar/18 ] |
|
The command, txnNumber, and stmtId should be knowable by the request that was sent that generated the WriteConflict. Getting more detail about why a WriteConflict occurred, however, is difficult. WriteConflicts are generated any time wired tiger rolls back a WT transaction for any reason, and the storage engine API currently doesn't have a way to pass information about why the transaction failed back up from WT to MongoDB. michael.cahill |