[SERVER-82281] ShardingTest.js Does Not Merge Multiple SetParameters Properly Created: 17/Oct/23  Updated: 12/Dec/23

Status: Backlog
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Brett Nawrocki Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: cs-subteam1, neweng, sharding-nyc-subteam1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Cluster Scalability
Operating System: ALL
Participants:
Linked BF Score: 5
Story Points: 4

 Description   

ShardingTest will merge its parameters object with its own "other" field. However, if both the regular field and the other variant of that field contain a setParameter object, the regular field will be clobbered in favor of the other field, instead of merging the parameters.

For example, the continuous stepdown suite sets the other config server log verbosity, and the resharding test fixture sets the regular critical section timeout. The resulting params object to ShardingTest looks like this:

{
    "mongos": 1,
    "mongosOptions": {
        "setParameter": {}
    },
    "config": 1,
    "configOptions": {
        "setParameter": {
            "reshardingCriticalSectionTimeoutMillis": 86400000
        }
    },
    "shards": 3,
    "rs": {
        "nodes": 2
    },
    "rsOptions": {
        "setParameter": {
            "maxNumberOfTransactionOperationsInSingleOplogEntry": 1
        },
        "oplogSize": 256
    },
    "configReplSetTestOptions": {},
    "manualAddShard": true,
    "configShard": false,
    "other": {
        "configOptions": {
            "setParameter": {
                "logComponentVerbosity": "{\n\t\"verbosity\" : 0,\n\t\"command\" : {\n\t\t\"verbosity\" : 1\n\t},\n\t\"network\" : {\n\t\t\"verbosity\" : 1,\n\t\t\"asio\" : {\n\t\t\t\"verbosity\" : 2\n\t\t}\n\t},\n\t\"tracking\" : {\n\t\t\"verbosity\" : 0\n\t}\n}"
            }
        }
    }
}

And after merging, it will look like this:

{
    "mongos": 1,
    "mongosOptions": {
        "setParameter": {}
    },
    "config": 1,
    "configOptions": {
        "setParameter": {
            "logComponentVerbosity": "{\n\t\"verbosity\" : 0,\n\t\"command\" : {\n\t\t\"verbosity\" : 1\n\t},\n\t\"network\" : {\n\t\t\"verbosity\" : 1,\n\t\t\"asio\" : {\n\t\t\t\"verbosity\" : 2\n\t\t}\n\t},\n\t\"tracking\" : {\n\t\t\"verbosity\" : 0\n\t}\n}"
        }
    },
    "shards": 3,
    "rs": {
        "nodes": 2
    },
    "rsOptions": {
        "setParameter": {
            "maxNumberOfTransactionOperationsInSingleOplogEntry": 1
        },
        "oplogSize": 256
    },
    "configReplSetTestOptions": {},
    "manualAddShard": true,
    "configShard": false,
    "other": {
        "configOptions": {
            "setParameter": {
                "logComponentVerbosity": "{\n\t\"verbosity\" : 0,\n\t\"command\" : {\n\t\t\"verbosity\" : 1\n\t},\n\t\"network\" : {\n\t\t\"verbosity\" : 1,\n\t\t\"asio\" : {\n\t\t\t\"verbosity\" : 2\n\t\t}\n\t},\n\t\"tracking\" : {\n\t\t\"verbosity\" : 0\n\t}\n}"
            }
        }
    }
}

This has lead to at least one failure in BF-28593 where the critical section timed out due to the timeout parameter not being extended as expected.


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