[SERVER-76481] RSLocalClient should not manually implement readConcern Created: 25/Apr/23  Updated: 25/Oct/23

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

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-76107 Allow to use snapshotReadConcern in q... Backlog
Assigned Teams:
Storage Execution
Operating System: ALL
Sprint: Execution NAMR Team 2023-09-18
Participants:

 Description   

The RSLocalClient::queryOnce manually implements majority read concern for its callers. It also does some complex work of stashing the previous ReadSource so that it doesn't affect the caller's RecoveryUnit state.

We should really be doing this work inside waitForReadConcern() and have the caller pass a "readConcern" to the FindCommandRequest in the DBDirectClient. This should work correctly.

Ideally inside waitForReadConcern(), if we're in a DirectClient call, we would assert that the caller does not have an active RecoveryUnit then use the existing code to set the ReadSource on the RecoveryUnit based on the requested readConcern. We may need to implement something inside DBDirectClient to push our ReadSource onto the stack somehow so that when we're done with the DBDirectClient call, we reset the original RecoveryUnit state.



 Comments   
Comment by Louis Williams [ 19/Sep/23 ]

This is really complicated for many reasons. We just don't have a good, consistent, internal read API. All of the users of DBDirectClient want different things. Going to put this in the backlog and schedule a project to try to tackle this.

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