Sharding DDL coordinators should fail early on CommandNotFound

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • ALL
    • CAR Team 2026-08-31, CAR Team 2026-09-14
    • 🟥 DDL
    • None
    • None
    • None
    • None
    • None
    • None

      Since SERVER-57859 added CommandNotFound to isRetriableErrorForDDLCoordinator, the coordinator retry loop treats this error as retriable unconditionally.

      Most coordinators use _mustAlwaysMakeProgress to force retries only after entering a phase where catalog modifications or cleanup obligations cannot be rolled back. During earlier phases, CommandNotFound can indicate an incompatible participant binary in a multiversion deployment. Retrying in that case prevents the operation from failing promptly and can leave it retrying indefinitely.

      Adjust the retry handling so CommandNotFound is not retried before the coordinator has reached its progress-required phase, while preserving retries needed to complete cleanup after catalog modifications. The current retry decision is in the sharding coordinator retry loop.

      Potentially related tickets:

      • SERVER-115204, Backlog: mark DropIndexesCoordinator as always making progress after freezeMigrations.
      • SERVER-117615, Closed: coordinator cleanup after migrations are frozen.
      • SERVER-121383, Closed: coordinator cleanup after blocking writes and setFCV.
      • SERVER-73929, Closed: resilient movePrimary error handling.

            Assignee:
            Tommaso Tocci
            Reporter:
            Tommaso Tocci
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: