[DOCS-11493] Document which errors abort transactions Created: 26/Mar/18 Updated: 30/Oct/23 Resolved: 03/Apr/18 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | errors, transactions | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Days since reply: | 30 weeks, 5 days ago | ||||||||||||
| Epic Link: | DOCS: 4.0 Server | ||||||||||||
| Story Points: | 0.5 | ||||||||||||
| Description |
|
We knew when we designed transactions that some errors would cause a transaction to abort. For example, a write conflict, or a transaction that has been open too long and includes too many writes. Additionally there are surprising scenarios that we didn't originally intend. For example, a DuplicateKeyError aborts the transaction, see |
| Comments |
| Comment by Adrian Gierakowski [ 07/Jul/23 ] | |
|
So where can I could I learn about all errors which could abort a transaction? It would be useful to know about any such cases since, at least in the case of duplicate key error, moving code from running outside a transaction to with one, requires a refactor (since outside a tx I can recover from a duplicate key error, while within tx I cannot). It would be great to know if there are any other such cases. Thanks! | |
| Comment by Kay Kim (Inactive) [ 04/Apr/18 ] | |
|
The comment here is fine as it's linked to the txn documentation ticket, which also has the link to the ticket that aborted transactions are still audited. When txn docs start, the initial scoping will be to audit the linked tickets and cull the comments/descriptions so that we can group/combine tickets and update the txn ticket. | |
| Comment by Shannon Bradshaw (Inactive) [ 03/Apr/18 ] | |
|
kay.kim, where did you / do you want to capture spencer's comment so that we roll it into the transactions docs? | |
| Comment by Spencer Brody (Inactive) [ 03/Apr/18 ] | |
|
We decided today that we won't list exactly which error codes abort transactions and which don't, since those are subject to change over time. Instead we'll focus the docs around how users should respond to errors, which is that they should always try to abort the transaction when they receive an error. | |
| Comment by Spencer Brody (Inactive) [ 02/Apr/18 ] | |
|
alyson.cabral, do you think if a user sends a malformed request, or an illegal operation of some kind (for example trying to run dropCollection within a transaction, which isn't supported), the transaction should survive that request? Or should it implicitly abort the transaction, since almost all errors are going to implicitly abort the transaction, we might as well make it so all errors do so it's consistent and easy to understand? | |
| Comment by Spencer Brody (Inactive) [ 26/Mar/18 ] | |
|
FailedToParse, InvalidOptions, and IllegalOperation are probably the only errors I could conceive of us leaving the transaction open on. But if those are the only ones we're going to do it for, I kind of feel like it may be simpler not to do it for anything, then we have the simple story that all errors within a transaction abort that transaction. | |
| Comment by A. Jesse Jiryu Davis [ 26/Mar/18 ] | |
|
Even syntax errors like:
I'm just making sure we really mean all | |
| Comment by Spencer Brody (Inactive) [ 26/Mar/18 ] | |
|
Currently all errors abort the transaction. If we want, we can add a whitelist to the server to leave the transaction open on some error codes, but that work isn't currently planned. DuplicateKey was the main error I had been thinking would be valuable to keep the transaction open on, but we hit a technical roadblock that prevents us from keeping the transaction open on that error. |