-
Type: Bug
-
Resolution: Done
-
Priority: Critical - P2
-
Affects Version/s: 3.4.2, 3.5.1
-
Component/s: Sharding, Testing Infrastructure
-
None
-
Fully Compatible
-
ALL
-
-
Sharding 2017-04-17
As part of trying to reproduce SERVER-28545 outside of Jepsen, I've discovered that the background thread started by the sharding_continuous_config_stepdown.js override triggers a ReferenceError when attempting to run the "replSetStepDown" command. It therefore fails to ever actually send the "replSetStepDown" command to the current primary of the CSRS and causes the assert.throws() to silently succeed.
This defect was introduced by the changes in 76dc485 as part of SERVER-26903 by scoping the stepdownDelaySeconds variable outside of the _continuousPrimaryStepdownFn() function, thereby having the _continuousPrimaryStepdownFn() close over it. The _continuousPrimaryStepdownFn() function is passed to the ScopedThread constructor which executes in a fresh JavaScript context and therefore won't have this variable defined when invoked. Instead, the stepdownDelaySeconds value can be passed as an argument to the _continuousPrimaryStepdownFn() function.
Note: While it is effectively invalid to have a function run by a ScopeThread close over a variable from an outer scope, I have yet to figure out how to make our linters aware of the mongo shell's threading/process model.
- is duplicated by
-
SERVER-28549 pass stepdownDelaySeconds as an argument to _continuousPrimaryStepdownFn in continuous stepdown suite override
- Closed
- is related to
-
SERVER-26903 ShardingTest is failing non-retriable writes when the primary steps down because the stepdown suite turns the electionTimeoutMillis down from 10,000 ms to 5,000 ms
- Closed
-
SERVER-28567 assert.throws should validate that the correct exception was thrown
- Backlog