[SERVER-40631] Attach TransientTransactionError error label for network error codes in a transaction Created: 12/Apr/19 Updated: 29/Oct/23 Resolved: 16/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.11 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Sharding 2019-04-22 |
| Participants: |
| Description |
|
If a shard returns a network error to mongos in the course of a transaction, mongos will abort the transaction and return that error to the client. Currently these errors do not generate a transient transaction error label, so the client won't retry the the transaction at a higher txnNumber, but it would be safe to do so for every statement prior to commitTransaction (its unclear if commit was successful on a network error, so the commit needs to be retried with the same txnNumber to avoid double applying the transaction). This is in line with how drivers already treat network errors from single replica set transactions as transient errors. |
| Comments |
| Comment by Jack Mulrow [ 16/Apr/19 ] |
|
After discussion in the CR, network error codes were made transient transaction errors on both mongos and mongod since it's possible for shards to act as routers for certain commands, like aggregate with $lookup. |
| Comment by Githook User [ 16/Apr/19 ] |
|
Author: {'email': 'jack.mulrow@mongodb.com', 'name': 'Jack Mulrow', 'username': 'jsmulrow'}Message: |