[SERVER-62713] Ensure internal readers set explicit read concerns Created: 18/Jan/22  Updated: 21/Aug/23

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

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-62214 Use explicit read concern in InitialS... Closed
is related to SERVER-55699 Add an explicit write concern to inte... Closed
is related to SERVER-62664 Use explicit read concern in Sessions... Closed
is related to SERVER-62666 Use explicit read concern in Encrypte... Closed
is related to SERVER-62727 Use explicit read concern in BackupFi... Closed
Assigned Teams:
Replication
Sprint: Replication 2022-02-07, Repl 2022-02-21, Repl 2022-03-07, Repl 2022-03-21
Participants:

 Description   

SERVER-62214 and friends found cases where we didn't that can lead to concerning bugs. We should put in guardrails to prevent this from happening.



 Comments   
Comment by Judah Schvimer [ 24/Mar/22 ]

I'm a little concerned about implicitly using a default and internal readers not specifying what behavior they're relying on. I think forcing internal readers to choose a read concern is worthwhile, though I buy that it's not terribly urgent.

Comment by Samyukta Lanka [ 24/Mar/22 ]

I am not convinced that this is worth doing. We already ensure that all requests from internal clients specify some sort of read concern (even an empty one). There are several places where we automatically add an empty read concern to internal requests. We could still get rid of kImplicitDefault and always use local read concern instead, but I don't think this refactor benefits us much. I already mentioned above that an empty read concern can't be overridden by the cluster wide read concern, so this shouldn't be causing any bugs.

Comment by Samyukta Lanka [ 24/Feb/22 ]

We never actually override an empty read concern for an internal client because of this code (which also already asserts that internal readers use an explicit read concern), so I don't think there was ever a bug around this. As long as the request specified an empty read concern, it would not have been using the CWRC. However, this behavior is not obvious, which is why we thought a bug existed.

Comment by Samyukta Lanka [ 18/Jan/22 ]

This should involve getting rid of the ImplicitDefault read concern, since that could be overwritten by a cluster-wide default read concern.

Comment by Judah Schvimer [ 18/Jan/22 ]

SERVER-55699 did this for write concerns.

Generated at Thu Feb 08 05:55:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.