Mark fsync_lock_ddl_lock.js as stepdown incompatible

XMLWordPrintableJSON

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

      The sibling test are all marked as stepdown incompatible, this one was missing.
      The following timeline can cause a LockTimeout error on the stepdown hook, which causes a failure:

      - T1: test calls fsync on mongos
      - T1: mongos runs fsync on CSRS primary
      - T1: CSRS primary takes global S
      - T2: test hook calls replSetStepDown
      - T2: replSetStepDown marks CSRS as kReplicaSetNoPrimary
      - T2: replSetStepDown waits for global X (blocked by T1 global S)
      - T1: CSRS fsync returns to mongos
      - T1: mongos tries to resolve hosts from shardIds (appendRawResponses function)
      - T1: mongos tries to read config.shards from CSRS primary (stepdown forces shard catalog reload)
      - T1: mongos waits for CSRS primary (as replSetStepDown marked CSRS as ReplicaSetNoPrimary)
      --- deadlock ---
      - T2: replSetStepDown times out on waiting for global X
      - T2: replSetStepDown resets CSRS topology (kReplicaSetWithPrimary)
      - T1: mongos finds CSRS primary, refreshes, finishes fsync
      - T2: replSetStepDown reports LockTimeout to test hook
      - T2: test hook fails the test
      

            Assignee:
            Wolfee Farkas
            Reporter:
            Wolfee Farkas
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: