Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-34665

The mongo shell should retry writes on a WriteConcernFailure error response from the server

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.5, 4.0.0-rc0
    • Component/s: Shell
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v3.6
    • Sprint:
      TIG 2018-05-07
    • Linked BF Score:
      0

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              max.hirschhorn Max Hirschhorn
              Reporter:
              max.hirschhorn Max Hirschhorn
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: