-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Workload Resilience
-
Fully Compatible
-
Workload Resilience 2025-10-27
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
It's not necessary for the ARS to manually skip retrying requests with 'startTransaction' anymore because we correctly invalidate session and transaction state on failovers. In general, we rely on users of the ARS to pass the appropriate retry policy, and a retry policy other than kNoRetry for transaction requests should only be used for a small number of commands (read commands).
Background context: SERVER-49044 originally added this skip because at the time, we didn't correctly invalidate sessions and transactions, so retrying a txn request on a new primary would lead to an error during replication if the transaction ultimately committed. We now correctly invalidate transactions, and will not hit this error.
I've attached a repro of the initial issue that SERVER-49044 was seeking to solve, which shows we will successfully invalidate session and transaction state on a stepdown today, and can successfully commit even if we were to remove the manual skipping retrying on startTransaction.
- causes
-
SERVER-112931 Update mongos_not_retry_commands_in_transactions.js once we start retrying on startTransaction for read operations
-
- Closed
-
- is related to
-
SERVER-47645 Must invalidate all sessions on step down
-
- Closed
-
-
SERVER-49044 Make AsyncRequestSender not retry remote command requests with startTransaction=true
-
- Closed
-
- related to
-
SERVER-112931 Update mongos_not_retry_commands_in_transactions.js once we start retrying on startTransaction for read operations
-
- Closed
-
-
SERVER-113622 Shards acting as routers do not append transaction participants to error response when primary is force killed
-
- Needs Scheduling
-
-
SERVER-86467 Do not retry on error in the ARS or async rpc clients if request contains startOrContinueTransaction
-
- Closed
-