[SERVER-76553] Shapify readConcern's "afterClusterTime" and ensure we only use client-provided read/write concern values Created: 26/Apr/23  Updated: 25/Jan/24  Resolved: 22/May/23

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

Type: Task Priority: Major - P3
Reporter: Charlie Swanson Assignee: Backlog - Query Integration
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-85099 Tracking: Milestone 1 Closed
is depended on by SERVER-85105 Tracking: PM-2885 Milestone 0 Closed
Duplicate
duplicates SERVER-76919 add gen command fields to query stats... Closed
Related
related to SERVER-76919 add gen command fields to query stats... Closed
related to SERVER-85717 Shapify readConcern's 'atClusterTime'... Closed
Assigned Teams:
Query Integration
Participants:

 Description   

Two parts here after a thread in the design doc:
> You will have to normalize the read concerns, because the "afterClusterTime" argument's value is going to be different on pretty much every operation with causal consistency enabled. Maybe just change it to indicate that afterClusterTime was supplied, but don't reveal its value (because it would blow out your cache).

"normalize" being our usual 'serializeLiteral' shapification.

> [the telemetry key's read and write concerns] are the user-supplied read- and write-concern, or the system-applied ones? I presume the user-supplied values?

We intend the user-supplied - need to add a test which sets a cluster default (I don't remember how to do that but I'm sure there are other tests and also it is documented), and ensures that the defaulted value does not make it into the telemetry key.


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