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

Shutting down with prepared transaction can invariant during collection validation

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.2.0-rc3, 4.3.1
    • Affects Version/s: None
    • Component/s: Replication
    • Labels:
      None
    • Minor Change
    • ALL
    • v4.2
    • Hide
      --- a/jstests/replsets/shutdown_with_prepared_transaction.js
      +++ b/jstests/replsets/shutdown_with_prepared_transaction.js
      @@ -34,5 +34,5 @@
           jsTestLog("Shutting down the set with the transaction still in prepare state");
           // Skip validation during ReplSetTest cleanup since validate() will block behind the prepared
           // transaction's locks when trying to take a collection X lock.
      -    replTest.stopSet(null /*signal*/, false /*forRestart*/, {skipValidation: true});
      +    replTest.stopSet(null /*signal*/, false /*forRestart*/);
       }());
      
      Show
      --- a/jstests/replsets/shutdown_with_prepared_transaction.js +++ b/jstests/replsets/shutdown_with_prepared_transaction.js @@ -34,5 +34,5 @@ jsTestLog( "Shutting down the set with the transaction still in prepare state" ); // Skip validation during ReplSetTest cleanup since validate() will block behind the prepared // transaction's locks when trying to take a collection X lock. - replTest.stopSet( null /*signal*/ , false /*forRestart*/ , {skipValidation: true }); + replTest.stopSet( null /*signal*/ , false /*forRestart*/ ); }());
    • Repl 2019-07-15
    • 0

      If a test shuts down a node without committing or aborting a prepared transaction, collection validation will run into a prepare conflict. Previously, this would result in a hang. After SERVER-40936, this results in an invariant failure. While this is easy to avoid, it contradicts our general philosophy that we should not be able to hit invariants in tests. It might also be worth investigating if there are any other dangers that might come of this.

            Assignee:
            lingzhi.deng@mongodb.com Lingzhi Deng
            Reporter:
            vesselina.ratcheva@mongodb.com Vesselina Ratcheva (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: