-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: 5.0.0, 6.0.0, 7.0.0, 8.0.0-rc0, 7.3.0, 8.1.0-rc0
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v8.0, v7.0, v6.0, v5.0
-
CAR Team 2024-07-22, CAR Team 2024-08-05, CAR Team 2024-08-19
-
0
As part of running ShardingTest.stop, the shell will try and stop the CSRS. This will also involve running the post-test hooks on the test, like data consistency checks, which can involve the shell trying to talk directly to one of the config nodes. When this happens in a suite that steps down the config servers, the stepdowns make rollback possible, and on rollback a node will close all of its connections from the shell (because those connections don't mark themselves as Client::kKeepOpen). As a result, once the rollback closes the connection, the shell will fail when trying to use that connection.
Unlike replication suites like replica_sets_reconfig_jscore_stepdown_passthrough.yml which https://github.com/mongodb/mongo/blob/30809ea3a3dc3328080374e4825a7df342c5b08f/buildscripts/resmokeconfig/suites/replica_sets_reconfig_jscore_stepdown_passthrough.yml#L137 load a runCommand override to retry on network override, this sharding suite does not: sharding_csrs_continuous_config_stepdowns.
Usually this makes sense, because the tests will speak to mongos, which has its own internal retry logic to handle stepdowns. However, in a case like this where the testing infrastructure attempts to connection directly to a configserver node, it needs to be prepared for the connection to be closed by the server.
- is related to
-
SERVER-82706 check_metadata_consistency.js should use retriable writes when contacting config server
-
- Closed
-
-
SERVER-29174 Make direct writes against the config primary from a JS test throw in the continuous stepdown suite
-
- Closed
-