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