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

IDL accepts 'null' CommitQuorum type

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.0.0-rc4, 5.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Fully Compatible
    • ALL
    • v5.0
    • Hide

      noPassthrough reproducer:

      (function() {
"use strict";
const st = ShardingTest({shards: 1});
const mongos = st.s0;

var testDB = mongos.getDB('TopChunkDB')
assert.commandWorked(testDB.createCollection("twoPhaseIndexBuild"));

testDB.runCommand({
    setIndexCommitQuorum: 'twoPhaseIndexBuild',
    indexNames: ['a_1'],
    commitQuorum: null,
});

st.stop();
}());
      Show
      noPassthrough reproducer: (function() { "use strict" ; const st = ShardingTest({shards: 1}); const mongos = st.s0; var testDB = mongos.getDB( 'TopChunkDB' ) assert .commandWorked(testDB.createCollection( "twoPhaseIndexBuild" )); testDB.runCommand({ setIndexCommitQuorum: 'twoPhaseIndexBuild' , indexNames: [ 'a_1' ], commitQuorum: null , }); st.stop(); }());
    • Security 2021-06-28
    • 135

      There's a build failure where we run setIndexCommitQuorum with the following arguments:

      (gdb) p _opMsgRequest
$2 = {
  <mongo::OpMsg> = {
    body = owned BSONObj 214 bytes @ 0x7f8c0925ccbd = {
      [setIndexCommitQuorum] = "twoPhaseIndexBuild",
      [indexNames] = ["a_1"],
      [commitQuorum] = null,
      [$clusterTime] = {"clusterTime": {"$timestamp": {"t": 1623174548, "i": 15}}, "signature": {"hash": {"$binary": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "$type": "00"}, "keyId": 0}},
      [$db] = "TopChunkDB"
    }, 
    sequences = std::vector of length 0, capacity 0
  }, <No data fields>}

      The 'null' type isn't one of the acceptable values for CommitQuorum. See: https://github.com/mongodb/mongo/blob/f1370eb80c66f1439bc2ea135a2bf25e80eda1ed/src/mongo/db/catalog/commit_quorum.idl#L38-L42

      mark.benvenuto discovered a bug in the non-strict IDL parser that seems to be the cause of this.

            Assignee:
            mark.benvenuto@mongodb.com Mark Benvenuto
            Reporter:
            gregory.wlodarek@mongodb.com Gregory Wlodarek
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: