[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:
Related
related to SERVER-34059 DuplicateKeyError aborts transaction Closed
related to DOCS-11505 Document Transactions Closed
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 SERVER-34059. Let's find all the cases where a server error aborts the transaction.



 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?

CC jesse tess.avitabile

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:

{find: "collection", filter: {"$badOperator": 1}}

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.

Generated at Thu Feb 08 08:02:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.