[SERVER-79763] Default read concern setting is not being applied to TransactionRouter Created: 04/Aug/23  Updated: 20/Nov/23

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

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: sharding-nyc-subteam2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-79766 TransactionRouter ignores atClusterTi... Backlog
is related to SERVER-78949 Consider folding atClusterTime into r... Backlog
Assigned Teams:
Cluster Scalability
Operating System: ALL
Participants:
Story Points: 2

 Description   

The transaction router extracts the read concern settings here via beginOrContinue. However, in the command processing, we call beginOrContinue first, before applying the default settings to the operation context's read concern settings



 Comments   
Comment by Max Hirschhorn [ 15/Aug/23 ]

I don't believe the bug described by SERVER-79763 has any user impact from a transaction consistency perspective. This is because both starting a transaction with read concern level "majority" uses speculative majority behavior and behaves identically to starting a transaction with read concern level "level". We should still address the behavior of mongos so that logging for transactions reflects the cluster-wide read concern being used in sharded clusters as would have happened in a replica set.

As part of making these changes, SERVER-79763 should consider handling read concern level "available" being set as the cluster-wide default specially. This is because starting a transaction with read concern level "available" is not permitted and beginning to reject transactions when read concern level "available" was configured as the cluster-wide default would be harmful for an application on server version upgrade.

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