Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-76553

Shapify readConcern's "afterClusterTime" and ensure we only use client-provided read/write concern values

    • Type: Icon: Task Task
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Query Integration

      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.

            Assignee:
            backlog-query-integration [DO NOT USE] Backlog - Query Integration
            Reporter:
            charlie.swanson@mongodb.com Charlie Swanson
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: