-
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
- duplicates
-
SERVER-133278 Disable fsyncLock tests in sharding CSRS stepdown suites
-
- Closed
-