[SERVER-77458] Index diff checker in data_consistency_checker.js is too strict for server version 4.2 Created: 24/May/23  Updated: 29/Oct/23  Resolved: 01/Jun/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0, 7.0.0-rc3

Type: Bug Priority: Major - P3
Reporter: Rohan Sharan Assignee: Vishnu Kaushik
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v7.0
Sprint: Repl 2023-06-12
Participants:

 Description   

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.



 Comments   
Comment by Githook User [ 01/Jun/23 ]

Author:

{'name': 'kauboy26', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}

Message: SERVER-77458 Ignore field ordering when the ignoreFieldOrderForDataConsistency is set.
Branch: v7.0
https://github.com/mongodb/mongo/commit/18397c6e38a1e7836a5d7d33db119c00d616de06

Comment by Githook User [ 01/Jun/23 ]

Author:

{'name': 'kauboy26', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}

Message: SERVER-77458 Ignore field ordering when the ignoreFieldOrderForDataConsistency is set.
Branch: master
https://github.com/mongodb/mongo/commit/75b925cb1a27a79e895b53e4df3436ee99e1358e

Comment by Rohan Sharan [ 25/May/23 ]

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.

Generated at Thu Feb 08 06:35:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.