At the time when SERVER-31194 was implemented, the Driver's specification only permitted retrying a write operation on "not master" errors. Since retrying on error responses matching the WriteConcernError class was found to be necessary for the correctness of the retryable_writes_jscore_stepdown_passthrough.yml test suite, it was done behind a TestData parameter to avoid having any impact on the user-facing version of the mongo shell.

function isRetryableCode(code) {
    return ErrorCodes.isNetworkError(code) || ErrorCodes.isNotMasterError(code) ||
        // The driver's spec does not allow retrying on writeConcern errors, so only do so
        // when testing retryable writes.
        (jsTest.options().alwaysInjectTransactionNumber &&
          ErrorCodes.isWriteConcernError(code));
}

There is now a list of retryable errors which permits the following definition for isRetryableCode():

function isRetryableCode(code) {
    return ErrorCodes.isNetworkError(code) || ErrorCodes.isNotMasterError(code) ||
        ErrorCodes.isShutdownError(code) || ErrorCodes.WriteConcernFailed === code;
}

Furthermore, the runClientFunctionWithRetries() function in src/mongo/shell/session.js must explicitly trigger retargeting when using a replica set connection and a non-"not master" error response is returned before attempting its retry. The mongo shell would otherwise always retry sending the command request to the server that is in the process of stepping down or has stepped down already. The desired behavior can be achieved by exposing a way to call ReplicaSetMonitor::failedHost() from JavaScript.