Skip to content

Commit 03f12b3

Browse files
committed
Markdown formatting
1 parent 14870f2 commit 03f12b3

1 file changed

Lines changed: 28 additions & 26 deletions

File tree

  • source/client-side-operations-timeout/tests

source/client-side-operations-timeout/tests/README.md

Lines changed: 28 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -565,11 +565,11 @@ the ClientSession `defaultTimeoutMS` option, and once more with the timeout spec
565565

566566
Tests in this section MUST only run against replica sets and sharded clusters with server versions 4.4 or higher.
567567

568-
It is recommended that drivers run these tests with [jitter](../../transactions-convenient-api/transactions-convenient-api.md#clientsessionwithtransaction) disabled
569-
(set to 0) to reduce the likelihood of flakiness due to varying
568+
It is recommended that drivers run these tests with
569+
[jitter](../../transactions-convenient-api/transactions-convenient-api.md#clientsessionwithtransaction) disabled (set to
570+
0\) to reduce the likelihood of flakiness due to varying
570571
[backoff times](../../transactions-convenient-api/transactions-convenient-api.md#backoff-benefits).
571572

572-
573573
#### timeoutMS is refreshed for abortTransaction if the callback fails
574574

575575
1. Using `internalClient`, drop the `db.coll` collection.
@@ -613,41 +613,43 @@ It is recommended that drivers run these tests with [jitter](../../transactions-
613613

614614
2. Using `internalClient`, set the following fail point:
615615

616-
```javascript
617-
{
618-
configureFailPoint: "failCommand",
619-
mode: "alwaysOn",
620-
data: {
621-
failCommands: ["insert"],
622-
blockConnection: true,
623-
blockTimeMS: 25,
624-
errorCode: 24,
625-
errorLabels: ["TransientTransactionError"]
626-
}
627-
}
628-
```
616+
```javascript
617+
{
618+
configureFailPoint: "failCommand",
619+
mode: "alwaysOn",
620+
data: {
621+
failCommands: ["insert"],
622+
blockConnection: true,
623+
blockTimeMS: 25,
624+
errorCode: 24,
625+
errorLabels: ["TransientTransactionError"]
626+
}
627+
}
628+
```
629629

630630
3. Create a new MongoClient `client` with default settings.
631631

632632
4. Using `client`, create a new explicit `session` with `defaultTimeout=200ms`.
633633

634634
5. Initialize an `attempt` counter to `0`.
635635

636-
6. Using `session`, execute `withTransaction` with a callback that:-
636+
6. Using `session`, execute `withTransaction` with a callback that:-
637+
637638
- increment the `attempt` counter
638639
- Inserts the document `{ x: 1 }` into `db.coll`
639640

640-
7. Expect this to fail with a CSOT timeout error (this depends on the driver's error/exception type)
641-
`MongoOperationTimeoutException` for Java).
641+
7. Expect this to fail with a CSOT timeout error (this depends on the driver's error/exception type)
642+
`MongoOperationTimeoutException` for Java).
642643
643-
8. Verify that there has been at least 2 attempts to execute the `insert` command as part of the `withTransaction` call. (`attempt > 1`)
644+
8. Verify that there has been at least 2 attempts to execute the `insert` command as part of the `withTransaction` call.
645+
(`attempt > 1`)
644646
645-
**Rationale:** This test verifies that when `withTransaction` encounters transient transaction errors
646-
(such as lock acquisition failures with error code 24), the retry attempts share the same timeout budget rather than resetting it.
647-
Each retry consumes time from the original 200ms timeout, and the cumulative delay from retries exceeds the available time budget, resulting in a timeout error.
648-
This test also ensures that the driver does not throw the lock acquisition error directly to the user, but instead surfaces a timeout
649-
error after exhausting the retry attempts within the specified timeout.
650-
The timeout error thrown contains as a cause the last transient error encountered.
647+
**Rationale:** This test verifies that when `withTransaction` encounters transient transaction errors (such as lock
648+
acquisition failures with error code 24), the retry attempts share the same timeout budget rather than resetting it.
649+
Each retry consumes time from the original 200ms timeout, and the cumulative delay from retries exceeds the available
650+
time budget, resulting in a timeout error. This test also ensures that the driver does not throw the lock acquisition
651+
error directly to the user, but instead surfaces a timeout error after exhausting the retry attempts within the
652+
specified timeout. The timeout error thrown contains as a cause the last transient error encountered.
651653
652654
### 11. Multi-batch bulkWrites
653655

0 commit comments

Comments
 (0)