ExportXMLWordPrintableJSON

    • Type: Spec Change
    • Resolution: Unresolved
    • Priority: Unknown
    • None
    • Component/s: Unified Test Format
    • None
    • Needed - No Spec Changes
    • $i18n.getText("admin.common.words.hide")
      Key Status/Resolution FixVersion
      CDRIVER-6482 Blocked
      CXX-3593 Blocked
      CSHARP-6243 Blocked
      GODRIVER-4167 Blocked
      JAVA-6323 Blocked
      NODE-7869 Blocked
      PYTHON-6123 Blocked
      PHPLIB-1959 Blocked
      RUBY-3967 Blocked
      RUST-2511 Blocked
      $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 */ } #scriptField td.willNotDo { background-color: #FF0000; /* Red color code */ } /* Center-align the first row headers */ #scriptField th { text-align: center; } Key Status/Resolution FixVersion CDRIVER-6482 Blocked CXX-3593 Blocked CSHARP-6243 Blocked GODRIVER-4167 Blocked JAVA-6323 Blocked NODE-7869 Blocked PYTHON-6123 Blocked PHPLIB-1959 Blocked RUBY-3967 Blocked RUST-2511 Blocked

      Summary

      What is the problem or use case, what are we trying to achieve?

      source/transactions/tests/unified/error-labels-blockConnection.json ("add RetryableWriteError and UnknownTransactionCommitResult labels to connection errors") creates a single client with socketTimeoutMS: 100 and executes its failPoint operation through that same client.

      Unified test runners register the failpoint cleanup on the failpoint operation's client, so the cleanup disable also runs with a 100ms socket budget. This causes the cleanup to inconsistently fail even if the test passes.

      The fix is to follow the convention we use in CSOT and other similar tests: configure the failpoint through a separate client without timeout options set. The Unified Test Format spec should also be updated to specify that doing so is a requirement for all tests that use failpoints and timeout options together.

      Motivation

      Who is the affected end user?

      Who are the stakeholders?

      Drivers engineers

      How does this affect the end user?

      Are they blocked? Are they annoyed? Are they confused?

      Flaky tests are annoying

      How likely is it that this problem or use case will occur?

      Main path? Edge case?

      It occurs regularly (at least in Python)

      If the problem does occur, what are the consequences and how severe are they?

      Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?

      See above.

      Is this issue urgent?

      Does this ticket have a required timeline? What is it?

      No.

      Is this ticket required by a downstream team?

      Needed by e.g. Atlas, Shell, Compass?

      No.

      Is this ticket only for tests?

      Does this ticket have any functional impact, or is it just test improvements?

      Yes.

      Acceptance Criteria

      What specific requirements must be met to consider the design phase complete?
      Follow the convention we use in CSOT and other similar tests: configure the failpoint through a separate client without timeout options set.

      The Unified Test Format spec should also be updated to specify that doing so is a requirement for all tests that use failpoints and timeout options together.

            Assignee:
            Noah Stapp
            Reporter:
            Noah Stapp
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: