-
Type:
Spec Change
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Component/s: Unified Test Format
-
None
-
Needed - No Spec Changes
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.
- split to
-
CDRIVER-6482 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
CSHARP-6243 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
CXX-3593 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
GODRIVER-4167 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
JAVA-6323 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
NODE-7869 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
PHPLIB-1959 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
PYTHON-6123 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
RUBY-3967 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-
-
RUST-2511 Transactions unified test error-labels-blockConnection is flaky due to configuring its failpoint through a client with timeout options
-
- Blocked
-