Investigate if ShardingDDLCoordinators check feature flags inside AlternativeClientRegion

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Done
    • Priority: Major - P3
    • None
    • Affects Version/s: 8.3.0-rc0
    • Component/s: None
    • Catalog and Routing
    • Fully Compatible
    • CAR Team 2026-07-20, CAR Team 2026-08-03
    • 🟥 DDL
    • None
    • None
    • None
    • None
    • None
    • None

      Context: To avoid persisting metadata consistently, all feature flag checks inside ShardingDDLCoordinators must keep the same results through the execution of the DDL. We do this via OperationFCV (versionContext): We snapshot the FCV once at the beginning, persist it in the coordinator document, and propagate it to the phases and the participant commands.

       

      Problem: It's somewhat common that ShardingDDLCoordinator phases and participants, create a new OperationContext via AlternativeClientRegion (example). This new OperationContext won't keep the OperationFCV (SERVER-108921), so it will check feature flags against the global ServerFCV which may have already transitioned and thus see different feature flags. SERVER-118777 is an example of a bug caused by this.

       

      Proposal: Investigate current usages of AlternativeClientRegion in ShardingDDLCoordinator to confirm they don't check feature flags. If they do, we should propagate the OFCV (similar to the fix for SERVER-118777).

            Assignee:
            Vishesh Ruparelia
            Reporter:
            Joan Bruguera Micó
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: