If a transaction router receives a response without a readOnly value for an added participant, but it previously had that shard marked as readOnly, we mark the shard as "outstanding". The transaction router will treat this shard as a write shard at commit time to avoid accidentally choosing a read-optimized commit when it should not. It's possible that this shard is the only shard treated as a write shard in the commit protocol, and if so would be expected to be chosen as the recovery shard - the transaction router should pick a shard it is marking as 'outstanding' as the recovery shard if one has not yet been chosen for the transaction.
- is depended on by
-
SERVER-84470 Allow $lookup to target an unsplittable collection on a primary shard within a multi-document transaction
-
- Closed
-
- related to
-
-
- Closed
-
-
SERVER-90441 Ensure transaction participants which are outstanding to top-level TransactionRouter only did reads at time of prepare
-
- Backlog
-