[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:
Depends
Related
related to SERVER-34176 Decide on public name of WriteConflic... Closed
Backwards Compatibility: Minor Change
Sprint: Execution Team 2019-09-09
Participants:

 Description   

A WriteConflict error message provides very little information to the user:

{
  "ok": 0.0,
  "errmsg": "WriteConflict",
  "code": 112,
  "codeName": "WriteConflict",
  "operationTime": <time>,
  "$clusterTime": {},
}

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: SERVER-34180 Add more context to WriteConflict error message
Branch: master
https://github.com/mongodb/mongo/commit/4807c2165b552670c9fe66c79c6d5be34e845023

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.
Write conflict errors will only occur on non-static data (that is, in-flight transactions that are not yet committed), and thus they are highly transient. Any extra data in the error message won't be that valuable, as you wouldn't be able to modify your next plan of action with them. Even if you ignored any extra error information and retried the exact same operation again, it would be very likely that you would not receive another Write Conflict error in the same place, simply due to the nature of what causes Write Conflict errors.

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

Generated at Thu Feb 08 04:35:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.