-
Type: Bug
-
Resolution: Unresolved
-
Priority: Minor - P4
-
None
-
Component/s: Retryability
-
None
-
Needed
-
Summary
In DRIVERS-1483, a test is added to verify the the PoolClearedError is retryable. This test is flaky since we can have a situation where the pool is cleared by the first find/insert, but before the checkout for the second find/insert is done, the pool is readied again, causing the checkout to succeed and the test to fail (since it checks for a ConnectionCheckoutFailed). This ticket should change that test to fix the flakiness.
Motivation
Who is the affected end user?
Who are the stakeholders?
How does this affect the end user?
Are they blocked? Are they annoyed? Are they confused?
How likely is it that this problem or use case will occur?
Main path? Edge case?
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?
Is this issue urgent?
Does this ticket have a required timeline? What is it?
Is this ticket required by a downstream team?
Needed by e.g. Atlas, Shell, Compass?
Is this ticket only for tests?
Does this ticket have any functional impact, or is it just test improvements?
- split to
-
CDRIVER-5762 PoolClearedError test is flaky
- Blocked
-
CSHARP-5365 PoolClearedError test is flaky
- Blocked
-
CXX-3128 PoolClearedError test is flaky
- Blocked
-
GODRIVER-3386 PoolClearedError test is flaky
- Blocked
-
JAVA-5657 PoolClearedError test is flaky
- Blocked
-
NODE-6461 PoolClearedError test is flaky
- Blocked
-
PHPLIB-1554 PoolClearedError test is flaky
- Blocked
-
PYTHON-4911 PoolClearedError test is flaky
- Blocked
-
RUBY-3558 PoolClearedError test is flaky
- Blocked
-
RUST-2061 PoolClearedError test is flaky
- Blocked
-
MOTOR-1378 PoolClearedError test is flaky
- Closed