$listClusterCatalog doesn't see a consistent state between the config catalog and the shard/local catalog

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • CAR Team 2026-01-19
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Right now, the $listClusterCatalog first fetches all the collections from listCollections and later reads the collections on config.collections. Since these reads are not done at the same cluster time, both responses may be inconsistent between them.

      If the reads of the config catalog and the shard/local catalog are not consistent, $listClusterCatalog fields that rely on both catalogs could potentially return wrong information when there are concurrent DDL operations. Those fields are mainly 'shards', 'tracked' and 'sharded'.

      For instance:

      • If a resharding operation runs concurrently with $listClusterCatalog, $listClusterCatalog may return an empty list of shards if the collection is not present on the config catalog when $listClusterCatalog performs the read on config.collections.
      • If a shardCollection operation runs concurrently with $listClusterCatalog, $listClusterCatalog may return that the collection is sharded if it's not present on the config catalog when $listClusterCatalog performs the read on config.collections.

      This ticket aims to ensure that $listClusterCatalog makes consistent reads across the config catalog and the local/shard catalogs.

            Assignee:
            Silvia Surroca
            Reporter:
            Silvia Surroca
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: