[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 |