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

big_object1.js is not resilient to unexpected stepdowns

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.6, 4.0.1, 4.1.1
    • Component/s: None
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v4.0, v3.6
    • Sprint:
      Query 2018-07-02
    • Linked BF Score:
      16

      Description

      In one instance when this test was run in the retryable_writes_jscore_stepdown_passthrough, the primary receives a replSetStepDown command while the test's main insert loop is executing.

      [ReplicaSetFixture:job3:node2] 2018-05-01T18:15:45.659+0000 I COMMAND  [conn149] Attempting to step down in response to replSetStepDown command
      [ReplicaSetFixture:job3:node2] 2018-05-01T18:15:45.659+0000 I REPL     [conn149] transition to SECONDARY from PRIMARY
      

      Reading the code for this test, it looks like any sort of error is going to cause the while-loop to break prematurely.

          while (true) {
              var result;
              n = {_id: x, a: []};
              for (i = 0; i < 14 + x; i++)
                  n.a.push(s);
              try {
                  result = t.insert(n);
                  o = n;
              } catch (e) {
                  break;
              }
       
              if (result.hasWriteError())
                  break;
              x++;
          }
       
          printjson(t.stats(1024 * 1024));
       
          assert.lt(15 * 1024 * 1024, Object.bsonsize(o), "A1");
          assert.gt(17 * 1024 * 1024, Object.bsonsize(o), "A2");
      

      Having exited the loop without performing the needed inserts, the assertion fails.

      [js_test:big_object1] 2018-05-01T17:55:36.315+0000 2018-05-01T17:55:35.871+0000 E QUERY    [js] Error: 15728640 is not less than 13926560 : A1 :
      [js_test:big_object1] 2018-05-01T17:55:36.316+0000 doassert@src/mongo/shell/assert.js:18:14
      [js_test:big_object1] 2018-05-01T17:55:36.316+0000 _assertCompare@src/mongo/shell/assert.js:756:9
      [js_test:big_object1] 2018-05-01T17:55:36.317+0000 assert.lt@src/mongo/shell/assert.js:760:1
      [js_test:big_object1] 2018-05-01T17:55:36.317+0000 @jstests/core/big_object1.js:32:1
      [js_test:big_object1] 2018-05-01T17:55:36.320+0000 failed to load: jstests/core/big_object1.js
      

      If it were important for this test to be resilient in the face of unexpected stepdowns, we should rewrite the main insert loop, as it seems to be expecting to exit the loop for a particular reason (and not necessarily because a write failed due to a state change).

      However, I think that it would be easier to simply blacklist the test from the retryable_writes_jscore_stepdown_passthrough suite, as I can't really imagine how the coverage in the passthrough provides anything more than what is already achieved by running this test in jscore.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: