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

Standardize how we attach an afterClusterTime to the readConcern when doing config catalog queries

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Catalog and Routing

      Currently, in the ShardingCatalogClient, some aggregation calls such as getAllNssThatHaveZonesForDatabase and getHistoricalPlacement attach the after cluster time in the read concern.

      However, for 'find' config queries, we do not attach the after cluster time in the ShardingCatalogClient, but rather in the ShardRemote.

      It's not clear where we should attach the afterClusterTime, and whether it's done automatically by the shard remote or if it's something that needs to be handled by the ShardingCatalogClient itself. This inconsistent implementation can lead to causal consistency bugs.

      To address this issue, I suggest unifying all the places where we attach the afterClusterTime in the read concern when doing config queries. 

            Assignee:
            Unassigned Unassigned
            Reporter:
            pol.pinol@mongodb.com Pol Pinol
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: