-
Type: Bug
-
Resolution: Fixed
-
Priority: Critical - P2
-
Affects Version/s: None
-
Component/s: Testing Infrastructure
-
None
-
Fully Compatible
-
ALL
-
v3.6, v3.4
-
TIG 2018-02-12
The changes from b9decc4 as part of SERVER-21630 introduced a bug that causes the dbhash check to always be skipped on a replica set no matter how many voting secondaries it has.
Inside the isMultiNodeReplSet() function, the handling for when the isMaster response indicates the server is part of replica set shadows the outer hosts variable with another let declaration, thereby causing the array of connection strings to always be empty.
function isMultiNodeReplSet(uri) { const mongo = new Mongo(uri); let hosts = []; const isMaster = mongo.adminCommand({isMaster: 1}); if (isMaster.hasOwnProperty('setName')) { let hosts = isMaster.hosts; if (isMaster.hasOwnProperty('passives')) { hosts = hosts.concat(isMaster.passives); } } return hosts.length > 1; }
Note: JavaScripts that call ReplSetTest#checkReplicatedDataHashes() (e.g. from the work in SERVER-25640) aren't affected by this issue.
- causes
-
SERVER-34667 data_consistency_checks.js incorrectly assumes that the config.mongos collection always exists
- Closed
- is caused by
-
SERVER-21630 Expand resmoke's CheckReplDBHash support to config servers and sharded replica sets
- Closed
- is duplicated by
-
SERVER-33498 ReplSetTest.checkReplicaSet fails when run against a config server replica set.
- Closed
-
SERVER-24541 Add a test suite to test the JS hooks
- Closed
- related to
-
SERVER-37197 Validation failure does not cause test to fail
- Closed
-
SERVER-53854 checkReplicatedDataHashes() may return without throwing despite detecting a dbhash mismatch
- Closed
-
SERVER-34178 Address lingering issues around TestData.excludedDBsFromDBHash
- Closed