[SERVER-64663] Improve internal transaction API interactions with expected errors Created: 18/Mar/22  Updated: 27/Oct/23  Resolved: 19/Apr/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: Jack Mulrow
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Sharding NYC 2022-04-18, Sharding 2022-05-02
Participants:

 Description   

The internal transaction API assumes its transactions will succeed and will automatically attempt to commit if no errors are thrown, or abort if an exception is returned. If the transaction expects to hit some errors and wants to handle them specially, it can be difficult to disable the automatic commits/aborts which can throw errors that might swallow the expected error or trigger a transient transaction error retry. There's a similar issue with unyielding a ResourceYielder throwing an error if the underlying transaction aborted, which can also mask the original error.

The API should be improved to handle this use case more gracefully.



 Comments   
Comment by Jack Mulrow [ 19/Apr/22 ]

The issue with unyield errors taking precedence over transaction body errors was fixed in SERVER-63495 in this commit. That was the main problem, and the FLE code that tried to return a DuplicateKey error was obviated by using retryable writes and was removed, so closing this ticket as gone away.

Generated at Thu Feb 08 06:00:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.