Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2170

Errors on retryable ops should indicate originating server when possible

XMLWordPrintableJSON

    • Type: Icon: Spec Change Spec Change
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Component/s: Retryability
    • None
    • Needed
    • Hide

      Summary of necessary driver changes

      This only affects drivers that include server information (like the server name or address) in exceptions and error messages.

      Any driver that includes server information in an exception or error message must ensure that the exception or message refers to the server that originated the error. For example, during a retry of a failed read or write, the original server must not simply be carried over to a subsequent error.

      Show
      Summary of necessary driver changes This only affects drivers that include server information (like the server name or address) in exceptions and error messages. Any driver that includes server information in an exception or error message must ensure that the exception or message refers to the server that originated the error. For example, during a retry of a failed read or write, the original server must not simply be carried over to a subsequent error.
    • $i18n.getText("admin.common.words.hide")
      Key Status/Resolution FixVersion
      CDRIVER-4753 Backlog
      CXX-2776 Backlog
      CSHARP-4826 Works as Designed
      GODRIVER-3031 Works as Designed
      JAVA-5225 Works as Designed
      NODE-5719 Works as Designed
      MOTOR-1201 Duplicate
      PHPLIB-1296 Works as Designed
      RUBY-3340 Works as Designed
      RUST-1787 Works as Designed
      PYTHON-4137 Backlog
      $i18n.getText("admin.common.words.show")
      #scriptField, #scriptField *{ border: 1px solid black; } #scriptField{ border-collapse: collapse; } #scriptField td { text-align: center; /* Center-align text in table cells */ } #scriptField td.key { text-align: left; /* Left-align text in the Key column */ } #scriptField a { text-decoration: none; /* Remove underlines from links */ border: none; /* Remove border from links */ } /* Add green background color to cells with FixVersion */ #scriptField td.hasFixVersion { background-color: #00FF00; /* Green color code */ } /* Center-align the first row headers */ #scriptField th { text-align: center; } Key Status/Resolution FixVersion CDRIVER-4753 Backlog CXX-2776 Backlog CSHARP-4826 Works as Designed GODRIVER-3031 Works as Designed JAVA-5225 Works as Designed NODE-5719 Works as Designed MOTOR-1201 Duplicate PHPLIB-1296 Works as Designed RUBY-3340 Works as Designed RUST-1787 Works as Designed PYTHON-4137 Backlog

      While discussing some of the error reporting improvements that oleg.pudeyev has added to the Ruby driver, I learned that Ruby goes out of its way to report the specific server that produced an error ultimately reported when a retryable operation totally fails. This overcomes possible ambiguity where an operation can report an error message corresponding to the first or second attempt. Executing Retryable Write Commands states:

      If an error would not allow the caller to infer that an attempt was made (e.g. connection pool exception originating from the driver), the original error should be raised. If the retry failed due to another retryable error or some other error originating from the server, that error should be raised instead as the caller can infer that an attempt was made and the second error is likely more relevant (with respect to the current topology state).

      While Command Monitoring can also be used to infer the error's originating server, we can't rely on that being enabled in production systems where applications might only be logging an exception.

      The Retryable Reads spec does not appear to have any section discussing error reporting (possible oversight), but it should also be able to implement this.

      If a driver already attaches a server description (or equivalent) to its exceptions for server-side errors, I think they could implement this ticket just by ensuring that the attached server is always the originating server of the error being reported. For example, a driver that always attaches the first attempt's server to such an exception should be changed to conditionally attach the first or second accordingly.

            Assignee:
            jamis.buck@mongodb.com Jamis Buck
            Reporter:
            jmikola@mongodb.com Jeremy Mikola
            Andreas Braun Andreas Braun
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: