Major - P3 In moving the resmoke pin from server v6.0 to v7.0, I uncovered that the CleanEveryN hook was surfacing some issues for v4.2. Specifically, the bsonWoCompare here is too stringent for v4.2, because the fields in each index response can sometimes be out of order between nodes.
This happens on the source cluster, between a primary and a secondary node, so mongosync does not cause the issue.
This is an example of the index diff reported on v4.2:
[fsm_workload_test_try_catch:types_with_equivalent_values:CheckReplDBHash] 18:32:44.728Z sourceNode:
{
v: 2,
unique: true,
key: {
firstUniqueField: 1
},
name: "preExistedFSMIndexes_0",
ns: "test2_fsmdb0.fsmcoll0",
collation: {
locale: "en_US",
caseLevel: false,
caseFirst: "off",
strength: 2,
numericOrdering: false,
alternate: "non-ignorable",
maxVariable: "punct",
normalization: false,
backwards: false,
version: "57.1"
}
}
vs
[fsm_workload_test_try_catch:types_with_equivalent_values:CheckReplDBHash] 18:32:44.729Z syncingNode:
{
v: 2,
unique: true,
key: {
firstUniqueField: 1
},
name: "preExistedFSMIndexes_0",
collation: {
locale: "en_US",
caseLevel: false,
caseFirst: "off",
strength: 2,
numericOrdering: false,
alternate: "non-ignorable",
maxVariable: "punct",
normalization: false,
backwards: false,
version: "57.1"
},
ns: "test2_fsmdb0.fsmcoll0"
}
As you can see, the only difference is that the ns field is in a different location in the response.
This is slightly blocking the Mongosync 7.0 support epic, because we run this hook and it will fail out the suite. There is a workaround of skipping the offending suites, but we are losing test coverage.