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.