Changes

Author: sanych-sun

source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.md

@@ -599,16 +599,18 @@ response data is drained and the connection is ready to send the next command.
     check if at least one byte can be read/received. If at least one byte can be read the timestamp must be updated and
     connection SHOULD be drained. If no bytes can be read, the connection MUST be closed.
 3. **User-provided timeout**: If a user-provided timeout is specified for the operation, the driver MUST use the minimum
-    of (a) the remaining time before the 3 second "pending response" window elapses and (b) the user-provided timeout
-    as the effective timeout for the draining.
+    of (a) the remaining time before the 3 second "pending response" window elapses and (b) the remaining of
+    user-provided timeout as the effective timeout for the draining.
 4. **Default timeout**: If no user-provided timeout is specified, the driver MUST use the minimum of (a) the remaining 3
-    second "pending response" window and (b) the `socketTimeoutMS` (if supported by the driver) as the effective
-    timeout for the draining.
-5. **Error or over-age**: If any error other than timeout occurs while draining the pending response, or if the draining
+    second "pending response" window and (b) the `waitQueueTimeoutMS` (if not supported by the driver remaining of
+    `serverSelectionTimeoutMS` should be used instead) as the effective timeout for the draining.
+5. **On Timeout**: if timeout occurred while draining the pending response and the 3 seconds pending-response window was
+    not elapsed, Driver SHOULD return the connection to the pool, so the next operation can continue draining of the
+    pending response.
+6. **Error or over-age**: If any error other than timeout occurs while draining the pending response, or if the draining
     exceeds the 3 seconds pending-response window, the driver MUST close the connection. Driver SHOULD try to make
-    another checkout attempt if timeout is not reached yet or create a new connection according to the Checking Out a
-    Connection behavior.
-6. **Clear pending state on success**: If the pending response is fully drained, the pending response state MUST be
+    another checkout attempt accordingly to the Checking Out a Connection behavior.
+7. **Clear pending state on success**: If the pending response is fully drained, the pending response state MUST be
     cleared and connection can be used to execute the next command.
 
 ```mermaid
@@ -653,12 +655,11 @@ sequenceDiagram
     end
 ```
 
-````text
 ##### Pseudocode
 
 This subsection outlines the pseudocode steps for acquiring a connection from the pool.
 
-```python
+```text
 connection = Null
 tConnectionCheckOutStarted = current instant (use a monotonic clock if possible)
 emit ConnectionCheckOutStartedEvent and equivalent log message
@@ -677,8 +678,8 @@ try:
         if connection is in "pending response" state:
           drain the pending response
           if error:
-          	if non-timeout error:
-          	  close connection
+            if non-timeout error:
+              close connection
               connection = Null
             else if timeout error and last read timestamp on connection > 3 seconds old
               close connection
@@ -739,7 +740,7 @@ do asynchronously:
 tConnectionCheckedOut = current instant (use a monotonic clock if possible)
 emit ConnectionCheckedOutEvent(duration = tConnectionCheckedOut - tConnectionCheckOutStarted) and equivalent log message
 return connection
-````
+```
 
 #### Checking In a Connection