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