Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
34 commits
Select commit Hold shift + click to select a range
588f1f2
initial commit
baileympearson Nov 25, 2025
e467f5b
new files
baileympearson Nov 26, 2025
d55fdb9
add tests for handshake changes
baileympearson Nov 26, 2025
8e74b41
add generated tests
baileympearson Dec 1, 2025
072b453
test fixes and add prose test
baileympearson Dec 1, 2025
52e2a35
fix run on requirements
baileympearson Dec 2, 2025
391c951
fix run on requirements?
baileympearson Dec 2, 2025
92501c0
fix CI
baileympearson Dec 2, 2025
0fdef39
comments
baileympearson Dec 3, 2025
82acab8
Fix broken unified tests
baileympearson Dec 3, 2025
b3a7b6c
fix UTR linting failures
baileympearson Dec 3, 2025
60a87b8
remove broken deleteMany() from unified tests
baileympearson Dec 3, 2025
399a56b
add backwards compat section
baileympearson Dec 10, 2025
0545e15
Jeff's and Jib's comments
baileympearson Dec 11, 2025
ff5475a
adjust backpressure spec phrasing to make it clear retryable errors a…
baileympearson Dec 11, 2025
6211624
squash: jeremy's casing comments
baileympearson Dec 11, 2025
c1001bc
squash: other comments
baileympearson Dec 11, 2025
def5fbd
squash: other comments
baileympearson Dec 11, 2025
08da5c4
last round comments
baileympearson Dec 11, 2025
034b85e
unified retry loop, handshake phrasing change
baileympearson Dec 15, 2025
779e171
Jeremy's last comments
baileympearson Dec 15, 2025
e5d4de6
Other misc comments
baileympearson Dec 16, 2025
1cd95fc
update transaction spec and add unified tests
blink1073 Dec 17, 2025
6912e45
update transaction logic and add more tests
blink1073 Dec 17, 2025
88e6067
verify commitTransaction fails after 5 backoff attempts
blink1073 Dec 18, 2025
2019678
clean up transactions spec
blink1073 Dec 18, 2025
d3ce32b
update test names
blink1073 Dec 18, 2025
de7e862
address writeconcern on retries
blink1073 Dec 18, 2025
ab85a5b
add retryable get more tests
baileympearson Dec 18, 2025
eb10ddb
transaction test fixes
baileympearson Dec 18, 2025
2b90697
deduplicate ids
baileympearson Dec 18, 2025
0abf373
update transaction writeconcern logic and add changelog entry
blink1073 Dec 18, 2025
d07d49e
last few comments
baileympearson Dec 18, 2025
747c18c
add runOnRequirement for getMore tests
blink1073 Dec 19, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
337 changes: 337 additions & 0 deletions source/client-backpressure/client-backpressure.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specification introduces the overload retry policy, but similarly to the design, omits a very important piece: how should the current retry policy and the overload retry policy coexist? At the very least, the specification should cover the following (generally speaking, it's better if it does that by clearly expressing a principle from which the answers may be easily derived, rather than answering each question explicitly, as there may be more questions that have to be answered that I did not think about at the moment):

  1. Is it possible to encounter a failed attempt that is is eligible for a retry by both the current and the overload policy?
    1.1. I suspect, it currently is not, because the overload retry policy for now requires both RetryableError and SystemOverloadedError to be present. However, he specification should make the answer clear.
  2. What happens if the first attempt (so not a retry attempt) fails in a way that triggers a retry attempt according to the overload retry policy, and then the second attempt (the first retry attempt) fails in a way that could have triggered a retry attempt according to the current retry policy?
    2.1. The same question is for two attempts a(n), a(n+1) where the latter immediately1 follows the former, with the former, a(n), not being the first attempt.
    2.1.1. Note that such a situation may be encountered more than once for a single operation.
  3. What happens if the first attempt (so not a retry attempt) fails in a way that triggers a retry attempt according to the current retry policy, and then the second attempt (the first retry attempt) fails in a way that could have triggered a retry attempt according to the overload retry policy?
    3.1. The same question is for two attempts a(n), a(n+1) where the latter immediately1 follows the former, with the former, a(n), not being the first attempt.
    3.1.1. Note that such a situation may be encountered more than once for a single operation.
  4. The current retry policy for reads and writes specify which error is to be propagated to an application (if all attempts fail, there are multiple errors to choose from). The proposed overload retry policy does not do this even within itself; it should further specify which error is to be propagated to an application when some attempts of the same requested operation are done according to the current retry policy, while others are done according to the overload retry policy.

1 In terms of ordering relations, not in the temporal sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The updated pseudocode should answer these questions - let me know if there's anything else you'd like clarified.

Large diffs are not rendered by default.

57 changes: 57 additions & 0 deletions source/client-backpressure/tests/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
# Client Backpressure Tests

______________________________________________________________________

## Introduction

The YAML and JSON files in this directory are platform-independent tests meant to exercise a driver's implementation of
retryable reads. These tests utilize the [Unified Test Format](../../unified-test-format/unified-test-format.md).

Several prose tests, which are not easily expressed in YAML, are also presented in this file. Those tests will need to
be manually implemented by each driver.

### Prose Tests

#### Test 1: Operation Retry Uses Exponential Backoff

Drivers should test that retries do not occur immediately when a SystemOverloadedError is encountered.

1. Let `client` be a `MongoClient`
2. Let `collection` be a collection
3. Now, run transactions without backoff:
1. Configure the random number generator used for jitter to always return `0` -- this effectively disables backoff.

2. Configure the following failPoint:

```javascript
{
configureFailPoint: 'failCommand',
mode: 'alwaysOn',
data: {
failCommands: ['insert'],
errorCode: 2,
errorLabels: ['SystemOverloadedError', 'RetryableError']
}
}
```

3. Insert the document `{ a: 1 }`. Expect that the command errors. Measure the duration of the command execution.

```javascript
const start = performance.now();
expect(
await coll.insertOne({ a: 1 }).catch(e => e)
).to.be.an.instanceof(MongoServerError);
const end = performance.now();
```

4. Configure the random number generator used for jitter to always return `1`.

5. Execute step 3 again.

6. Compare the two time between the two runs.
```python
assertTrue(with_backoff_time - no_backoff_time >= 2.1)
```
The sum of 5 backoffs is 3.1 seconds. There is a 1-second window to account for potential variance between the two
runs.
Loading