[SERVER-69480] TransientTransactionError label potentially applied incorrectly Created: 06/Sep/22 Updated: 22/Nov/22 Resolved: 22/Nov/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Alex Bevilacqua | Assignee: | Yujin Kang Park |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: | 1. Setup Environment (single node replica set, MongoDB 6.0.1)
2. Test with C# Driver (2.17.1 / .NET 6.0)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2022-10-31, Execution Team 2022-11-28 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
The log message for MongoDB 6.0 is:
Previously (MongoDB 5.0) this was logged as follows (likely due to
The transactions specification (Interaction with Retryable Writes) indicates that:
It appears here that the failure isn't with the write itself but updating the indexes. Should this still be labelled as a TransientTransactionError? Screenshot of the reproduction running in Visual Studio 2022 below: |
| Comments |
| Comment by Yujin Kang Park [ 22/Nov/22 ] |
|
We verified with the reproducer (converted to JS) server-69480.js Some more details can be found here: |
| Comment by Louis Williams [ 31/Oct/22 ] |
|
For those watching, we are implementing this work in an existing ticket, |
| Comment by Louis Williams [ 20/Sep/22 ] |
|
For watchers, there's a lot of context and history related to this in WiredTiger can roll back a transaction for multiple reasons. Usually, it's due to a write-write conflict with another transaction. In the case of this application, they're creating very large transaction that is too big for the cache. WiredTiger, in attempt to free up space, starts rolling back transactions, starting from the oldest. Eventually, it gets to the transaction causing problems and rolls it back. In MongoDB we don't know why WiredTiger rolled back the transaction, which is why we implemented As far as solutions, we could return a non-retryable TemporarilyUnavailable error code in this circumstance. We already return this for non-multi-doc transactions writes as of 6.1 ( We are also considering another solution, |
| Comment by Alex Bevilacqua [ 20/Sep/22 ] |
|
louis.williams@mongodb.com 5.0 and 6.0 are functionally (and I believe behaviorally) the same - only what is logged is different. |
| Comment by Louis Williams [ 20/Sep/22 ] |
|
alex.bevilacqua@mongodb.com can you clarify whether or not there was a behavioral change between 5.0 and 6.0? I see that you posted the log messages from both versions, but is there a behavioral difference? |