Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-28547

sharding_continuous_config_stepdown suite doesn't actually step any nodes down

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      diff --git a/jstests/libs/override_methods/sharding_continuous_config_stepdown.js b/jstests/libs/override_methods/sharding_continuous_config_stepdown.js
      index 638dc8bb29..2f242591fd 100644
      --- a/jstests/libs/override_methods/sharding_continuous_config_stepdown.js
      +++ b/jstests/libs/override_methods/sharding_continuous_config_stepdown.js
      @@ -90,8 +92,13 @@ tracking: {verbosity: 0} }";
                           print('*** Stepping down ' + primary);
       
                           assert.throws(function() {
      -                        var result = primary.adminCommand(
      -                            {replSetStepDown: stepdownDelaySeconds, force: true});
      +                        try {
      +                            var result = primary.adminCommand(
      +                                {replSetStepDown: stepdownDelaySeconds, force: true});
      +                        } catch (e) {
      +                            print("!!! " + tojson(e));
      +                            throw e;
      +                        }
                               print('replSetStepDown command did not throw and returned: ' +
                                     tojson(result));
      
      

      $ python buildscripts/resmoke.py --executor=sharding_continuous_config_stepdown jstests/sharding/addshard1.js
      ...
      [js_test:addshard1] 2017-03-29T16:46:16.488-0400 *** Stepping down connection to localhost:20011
      [js_test:addshard1] 2017-03-29T16:46:16.492-0400 !!! ReferenceError: stepdownDelaySeconds is not defined
      

      Show
      diff --git a/jstests/libs/override_methods/sharding_continuous_config_stepdown.js b/jstests/libs/override_methods/sharding_continuous_config_stepdown.js index 638dc8bb29..2f242591fd 100644 --- a/jstests/libs/override_methods/sharding_continuous_config_stepdown.js +++ b/jstests/libs/override_methods/sharding_continuous_config_stepdown.js @@ -90,8 +92,13 @@ tracking: {verbosity: 0} }"; print('*** Stepping down ' + primary);   assert.throws(function() { - var result = primary.adminCommand( - {replSetStepDown: stepdownDelaySeconds, force: true}); + try { + var result = primary.adminCommand( + {replSetStepDown: stepdownDelaySeconds, force: true}); + } catch (e) { + print("!!! " + tojson(e)); + throw e; + } print('replSetStepDown command did not throw and returned: ' + tojson(result)); $ python buildscripts/resmoke.py --executor=sharding_continuous_config_stepdown jstests/sharding/addshard1.js ... [js_test:addshard1] 2017-03-29T16:46:16.488-0400 *** Stepping down connection to localhost:20011 [js_test:addshard1] 2017-03-29T16:46:16.492-0400 !!! ReferenceError: stepdownDelaySeconds is not defined
    • Sprint:
      Sharding 2017-04-17

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: