[SERVER-37237] Consolidate read concern handling on mongos Created: 20/Sep/18  Updated: 06/Dec/22  Resolved: 05/Mar/19

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

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: ShardedTxn:RouterSupport, ShardingTechDebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Participants:

 Description   

Currently many of the commands on mongos handle read concern separately, e.g. sometimes through a helper class for parsing like QueryRequest (find) or AggregationRequest (aggregate), or sometimes by passing the BSON from the client through after filtering it (distinct). This makes it tricky to change the read concern in a transaction when picking a new global read timestamp or to upconvert read concern to level snapshot like single replica set transactions do. If the way these commands handle read concern could be consolidated to use a single source of truth, like the operation context decoration used by mongod, then modifying the read concern for a transaction would be much simpler.


Generated at Thu Feb 08 04:45:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.