|
| 1 | +# Retryable Reads Tests |
| 2 | + |
| 3 | +______________________________________________________________________ |
| 4 | + |
| 5 | +## Introduction |
| 6 | + |
| 7 | +The YAML and JSON files in this directory are platform-independent tests meant to exercise a driver's implementation of |
| 8 | +retryable reads. These tests utilize the [Unified Test Format](../../unified-test-format/unified-test-format.md). |
| 9 | + |
| 10 | +Several prose tests, which are not easily expressed in YAML, are also presented in this file. Those tests will need to |
| 11 | +be manually implemented by each driver. |
| 12 | + |
| 13 | +## Prose Tests |
| 14 | + |
| 15 | +### 1. PoolClearedError Retryability Test |
| 16 | + |
| 17 | +This test will be used to ensure drivers properly retry after encountering PoolClearedErrors. It MUST be implemented by |
| 18 | +any driver that implements the CMAP specification. This test requires MongoDB 4.2.9+ for `blockConnection` support in |
| 19 | +the failpoint. |
| 20 | + |
| 21 | +1. Create a client with maxPoolSize=1 and retryReads=true. If testing against a sharded deployment, be sure to connect |
| 22 | + to only a single mongos. |
| 23 | + |
| 24 | +2. Enable the following failpoint: |
| 25 | + |
| 26 | + ```javascript |
| 27 | + { |
| 28 | + configureFailPoint: "failCommand", |
| 29 | + mode: { times: 1 }, |
| 30 | + data: { |
| 31 | + failCommands: ["find"], |
| 32 | + errorCode: 91, |
| 33 | + blockConnection: true, |
| 34 | + blockTimeMS: 1000 |
| 35 | + } |
| 36 | + } |
| 37 | + ``` |
| 38 | + |
| 39 | +3. Start two threads and attempt to perform a `findOne` simultaneously on both. |
| 40 | + |
| 41 | +4. Verify that both `findOne` attempts succeed. |
| 42 | + |
| 43 | +5. Via CMAP monitoring, assert that the first check out succeeds. |
| 44 | + |
| 45 | +6. Via CMAP monitoring, assert that a PoolClearedEvent is then emitted. |
| 46 | + |
| 47 | +7. Via CMAP monitoring, assert that the second check out then fails due to a connection error. |
| 48 | + |
| 49 | +8. Via Command Monitoring, assert that exactly three `find` CommandStartedEvents were observed in total. |
| 50 | + |
| 51 | +9. Disable the failpoint. |
| 52 | + |
| 53 | +### 2. Retrying Reads in a Sharded Cluster |
| 54 | + |
| 55 | +These tests will be used to ensure drivers properly retry reads on a different mongos. |
| 56 | + |
| 57 | +Note: this test cannot reliably distinguish "retry on a different mongos due to server deprioritization" (the behavior |
| 58 | +intended to be tested) from "retry on a different mongos due to normal SDAM behavior of randomized suitable server |
| 59 | +selection". Verify relevant code paths are correctly executed by the tests using external means such as a logging, |
| 60 | +debugger, code coverage tool, etc. |
| 61 | + |
| 62 | +#### 2.1 Retryable Reads Are Retried on a Different mongos When One is Available |
| 63 | + |
| 64 | +This test MUST be executed against a sharded cluster that has at least two mongos instances, supports `retryReads=true`, |
| 65 | +and has enabled the `configureFailPoint` command (MongoDB 4.2+). |
| 66 | + |
| 67 | +1. Create two clients `s0` and `s1` that each connect to a single mongos from the sharded cluster. They must not connect |
| 68 | + to the same mongos. |
| 69 | + |
| 70 | +2. Configure the following fail point for both `s0` and `s1`: |
| 71 | + |
| 72 | + ```javascript |
| 73 | + { |
| 74 | + configureFailPoint: "failCommand", |
| 75 | + mode: { times: 1 }, |
| 76 | + data: { |
| 77 | + failCommands: ["find"], |
| 78 | + errorCode: 6 |
| 79 | + } |
| 80 | + } |
| 81 | + ``` |
| 82 | + |
| 83 | +3. Create a client `client` with `retryReads=true` that connects to the cluster using the same two mongoses as `s0` and |
| 84 | + `s1`. |
| 85 | + |
| 86 | +4. Enable failed command event monitoring for `client`. |
| 87 | + |
| 88 | +5. Execute a `find` command with `client`. Assert that the command failed. |
| 89 | + |
| 90 | +6. Assert that two failed command events occurred. Assert that both events occurred on different mongoses. |
| 91 | + |
| 92 | +7. Disable the fail point on both `s0` and `s1`. |
| 93 | + |
| 94 | +#### 2.2 Retryable Reads Are Retried on the Same mongos When No Others are Available |
| 95 | + |
| 96 | +This test MUST be executed against a sharded cluster that supports `retryReads=true` and has enabled the |
| 97 | +`configureFailPoint` command (MongoDB 4.2+). |
| 98 | + |
| 99 | +1. Create a client `s0` that connects to a single mongos from the cluster. |
| 100 | + |
| 101 | +2. Configure the following fail point for `s0`: |
| 102 | + |
| 103 | + ```javascript |
| 104 | + { |
| 105 | + configureFailPoint: "failCommand", |
| 106 | + mode: { times: 1 }, |
| 107 | + data: { |
| 108 | + failCommands: ["find"], |
| 109 | + errorCode: 6 |
| 110 | + } |
| 111 | + } |
| 112 | + ``` |
| 113 | + |
| 114 | +3. Create a client `client` with `directConnection=false` (when not set by default) and `retryReads=true` that connects |
| 115 | + to the cluster using the same single mongos as `s0`. |
| 116 | + |
| 117 | +4. Enable succeeded and failed command event monitoring for `client`. |
| 118 | + |
| 119 | +5. Execute a `find` command with `client`. Assert that the command succeeded. |
| 120 | + |
| 121 | +6. Assert that exactly one failed command event and one succeeded command event occurred. Assert that both events |
| 122 | + occurred on the same mongos. |
| 123 | + |
| 124 | +7. Disable the fail point on `s0`. |
| 125 | + |
| 126 | +## Changelog |
| 127 | + |
| 128 | +- 2024-04-30: Migrated from reStructuredText to Markdown. |
| 129 | + |
| 130 | +- 2024-03-06: Convert legacy retryable reads tests to unified format. |
| 131 | + |
| 132 | +- 2024-02-21: Update mongos redirection prose tests to workaround SDAM behavior preventing execution of deprioritization |
| 133 | + code paths. |
| 134 | + |
| 135 | +- 2023-08-26: Add prose tests for retrying in a sharded cluster. |
| 136 | + |
| 137 | +- 2022-04-22: Clarifications to `serverless` and `useMultipleMongoses`. |
| 138 | + |
| 139 | +- 2022-01-10: Create legacy and unified subdirectories for new unified tests |
| 140 | + |
| 141 | +- 2021-08-27: Clarify behavior of `useMultipleMongoses` for `LoadBalanced` topologies. |
| 142 | + |
| 143 | +- 2019-03-19: Add top-level `runOn` field to denote server version and/or topology requirements requirements for the |
| 144 | + test file. Removes the `minServerVersion` and `topology` top-level fields, which are now expressed within `runOn` |
| 145 | + elements. |
| 146 | + |
| 147 | + Add test-level `useMultipleMongoses` field. |
| 148 | + |
| 149 | +- 2020-09-16: Suggest lowering heartbeatFrequencyMS in addition to minHeartbeatFrequencyMS. |
| 150 | + |
| 151 | +- 2021-03-23: Add prose test for retrying PoolClearedErrors |
| 152 | + |
| 153 | +- 2021-04-29: Add `load-balanced` to test topology requirements. |
0 commit comments