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

StaleConfig error is not retried as a first statement in a txn with FLE sharded collections

    • Type: Icon: Bug Bug
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 7.0.0, 8.0.0-rc0
    • Component/s: None
    • Catalog and Routing
    • ALL
    • CAR Team 2024-05-13
    • 10
    • 2

      Due to SERVER-80135, collection metadata refresh after a shard collection now occur asynchronously. This change should not impact tests, as it is correct to have nodes with unknown or cleared metadata.

      If an operation is run in a shard with cleared metadata, at the time the metadata is checked locally on the shard, it will trigger a StaleConfig error. The service entry point of the shard will handle this error and install the correct metadata. Then, it will either locally retry the operation or fail with StaleConfig waiting for the router to retry the op.

      However, if this error occurs in a FLE sharded collection, it is bubbled up to the router and not retried. In contrast, if the collection is not encrypted, it would have been retried.

      Consequently, there is a lack of parity between retrievability transactions in sharded collections and FLE sharded collections.

            Assignee:
            jordi.olivares-provencio@mongodb.com Jordi Olivares Provencio
            Reporter:
            pol.pinol@mongodb.com Pol Pinol
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: