You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/client-side-operations-timeout/tests/README.md
+28-26Lines changed: 28 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -565,11 +565,11 @@ the ClientSession `defaultTimeoutMS` option, and once more with the timeout spec
565
565
566
566
Tests inthis section MUST only run against replica sets and sharded clusters with server versions 4.4 or higher.
567
567
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
#### timeoutMS is refreshed for abortTransaction if the callback fails
574
574
575
575
1. Using `internalClient`, drop the `db.coll` collection.
@@ -613,41 +613,43 @@ It is recommended that drivers run these tests with [jitter](../../transactions-
613
613
614
614
2. Using `internalClient`, set the following fail point:
615
615
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
+
```
629
629
630
630
3. Create a newMongoClient`client`with default settings.
631
631
632
632
4. Using `client`, create a newexplicit`session`with`defaultTimeout=200ms`.
633
633
634
634
5. Initialize an `attempt` counter to `0`.
635
635
636
-
6. Using `session`, execute `withTransaction`with a callback that:-
636
+
6. Using `session`, execute `withTransaction`with a callback that:-
637
+
637
638
- increment the `attempt` counter
638
639
- Inserts the document`{ x: 1 }` into `db.coll`
639
640
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).
642
643
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`)
644
646
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.
0 commit comments