-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
Fully Compatible
-
v8.0
-
CAR Team 2024-05-13, CAR Team 2024-05-27, CAR Team 2024-06-10
-
200
In concurrency suites with stepdowns and crashes, the reshardingMinimumOperationDurationMillis server parameter is always set to 30 seconds in order to give retriable writes enough time to be complete across elections.
This implies that if we continuously run moveCollection in the background, the tests execution time may increase a lot and potentially lead to spurious failures due to LockBusy for concurrent operations waiting to acquire the DDL lock.
$ git grep reshardingMinimumOperationDurationMillis.*30 buildscripts/resmokeconfig/ buildscripts/resmokeconfig/suites/concurrency_sharded_kill_primary_with_balancer.yml: reshardingMinimumOperationDurationMillis: 30000 # 30 seconds buildscripts/resmokeconfig/suites/concurrency_sharded_multi_stmt_txn_kill_primary.yml: reshardingMinimumOperationDurationMillis: 30000 # 30 seconds buildscripts/resmokeconfig/suites/concurrency_sharded_multi_stmt_txn_terminate_primary.yml: reshardingMinimumOperationDurationMillis: 30000 # 30 seconds buildscripts/resmokeconfig/suites/concurrency_sharded_multi_stmt_txn_with_stepdowns.yml: reshardingMinimumOperationDurationMillis: 30000 # 30 seconds buildscripts/resmokeconfig/suites/concurrency_sharded_terminate_primary_with_balancer.yml: reshardingMinimumOperationDurationMillis: 30000 # 30 seconds buildscripts/resmokeconfig/suites/concurrency_sharded_with_stepdowns.yml: reshardingMinimumOperationDurationMillis: 30000 # 30 seconds buildscripts/resmokeconfig/suites/concurrency_sharded_with_stepdowns_and_balancer.yml: reshardingMinimumOperationDurationMillis: 30000 # 30 seconds