DRIVERS-2884 Avoid connection churn when operations timeout #1675

prestonvasquez · 2024-10-14T21:06:45Z

This PR implements the design for connection pooling improvements described in DRIVERS-2884, based on the CSOT (Client-Side Operation Timeout) spec. It addresses connection churn caused by network timeouts during operations, especially in environments with low client-side timeouts and high latency.

When a connection is checked out after a network timeout, the driver now attempts to resume and complete reading any pending server response (instead of closing and discarding the connection). This may require multiple checkouts.
Each pending response read is subject to a cumulative 3-second static timeout. The timeout is refreshed after each successful read, acknowledging that progress is being made. If no data is read and the timeout is exceeded, the connection is closed.

To reduce unnecessary latency, if the timeout has expired while the connection was idle in the pool, a non-blocking single-byte read is performed; if no data is available, the connection is closed immediately.
This update introduces new CMAP events and logging messages (PendingResponseStarted, PendingResponseSucceeded, PendingResponseFailed) to improve observability of this path.

Please complete the following before merging:

Update changelog.
Make sure there are generated JSON files from the YAML test files.
Test changes in at least one language driver. Go: GODRIVER-3173 Complete pending reads on conn checkout mongo-go-driver#1977
Test these changes against all server versions and topologies (including standalone, replica set, sharded
clusters, and serverless).

source/client-side-operations-timeout/tests/connection-churn.yml

ShaneHarvey · 2025-04-17T22:23:24Z

source/client-side-operations-timeout/tests/connection-churn.yml

+    # after maxTimeMS, whereas mongod returns it after 
+    # max(blockTimeMS, maxTimeMS).  Until this ticket is resolved, these tests 
+    # will not pass on sharded clusters.
+    topologies: ["standalone", "replicaset"]


standalone -> single

ShaneHarvey · 2025-04-17T23:36:46Z

source/client-side-operations-timeout/tests/connection-churn.yml

+      - name: findOne
+        object: *collection
+        arguments:
+          timeoutMS: 50


In python this timeout is too small and causes this find to fail before sending anything to the server. The same problem exists in the other tests too. Perhaps all of theses tests should run a setup command (eg ping) to ensure a connection is created and available in the pool, then run the finds. What do you think?

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

baileympearson · 2025-05-01T20:16:09Z

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

+
+#### Connection Aliveness Check Fails
+
+1. Initialize a mock TCP listener to simulate the server-side behavior. The listener should write at least 5 bytes to


Thoughts on adding a mock server to drivers-evergreen-tools for these tests? I could go either way - there are only two, so the burden on drivers isn't too great but it might be nice if drivers didn't need to worry about the mock server logic themselves.

I’m concerned that this solution will require drivers to spin up a server when trying to test locally. I’ve suggested DRIVERS-3183 to support raw-TCP connection test entities which will allow us to convert these prose tests to a unified spec test in the future.

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

baileympearson · 2025-05-02T15:14:21Z

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

+The next time the connection is checked out, the driver MUST attempt to read and discard the remaining response from the
+socket. The workflow for this is as follows:
+
+- The connection MUST persist the current time recorded immediately after the original socket timeout, and this


Not opposed to having the logic in the connection but we do have precedent for other connection state related-actions in checkIn (destroying the connection, etc). Would recording the start time make sense at checkIn instead of after the timeout in the driver's connection abstraction?

I have two thoughts on this. First, some drivers will likely add an object to the connection to maintain state for a pending response, for example:

type pendingResponseState struct { remainingBytes int32 requestID int32 start time.Time } type connection struct { // pendingResponseState contains information required to attempt a pending read // in the event of a socket timeout for an operation that has appended // maxTimeMS to the wire message. pendingResponseState *pendingResponseState }

It would be more pragmatic to update the current time where remainginBytes and requestID are assigned (which is when the socket times out).

Additionally, we want to start this “countdown” ASAP in case the connection is “dead”: in such cases the “aliveness check” will be a non-blocking failure while awaiting a pending response. Delaying when we set the current time reduces the likelihood (albeit small) that the 3 second pending response timeout has been exceeded while the connection remains idle in the pool.

Okay, leaving this where it is works for me. Thanks!

baileympearson · 2025-05-02T15:29:49Z

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

@@ -576,7 +576,106 @@ other threads from checking out [Connections](#connection) while establishing a
 Before a given [Connection](#connection) is returned from checkOut, it must be marked as "in use", and the pool's
 availableConnectionCount MUST be decremented.

-```text
+If an operation times out the socket while awaiting a server response and CSOT is enabled and `maxTimeMS` was added to
+the command, the driver MUST mark the connection as "pending" and record the current time in a way that can be updated.


So - I do understand this is the approach outlined in the design and that it is generally valuable to have example algoritims and pseudocode in the specification. However, I do think this approach makes assumptions about connection layer implementations and socket APIs that don't hold true for all drivers (at least in Node, they certainly don't). For example - Node's socket API is push-based and we collect chunks when they're available. Immediate reads do not make sense for our connection layer implementation and so the existing implementation of await_pending_response doesn't either.

I'm happy to work with you on the phrasing here but can we try to phrase these requirements in a way that outlines the requirements, and then outlines a particular implementation that satisfies the requirements? Ex: in Node, the socket API we use pushes chunks of data to us automatically (there is no read(n) method). We collect this into a buffer automatically when they're available. So when we implement these changes in Node, what we will likely do instead of this algorithm is:

on timeout, fail the current request and record the time of timeout but don't stop receiving data chunks from the socket.

set the socket's timeout to 3s (time out the socket if no chunks arrive in 3s)

in checkout, check if the pending connection has finished reading the response from the server. If it has, discard and continue. If not, calculate the wait time and wait. On success, proceed. On timeout, close the connection.

I think this approach still satisfies the goals of the spec changes but as the spec is currently written, our implementation would not be spec compliant. Thoughts?

IIUC in the Node case, bytes that have not been consumed will still sit on the socket after a timeout. So you would still need to read and discard any buffered data when checking out a connection that has been pinned to a pending response. The three bullet points you note do not conflict with the algorithm, AFAICT. I would be happy to troubleshoot this offline with you, though.

No, not exactly. Unless we explicitly disable this behavior, any data that arrives on the socket will actually be processed by the driver, even while the connection is checked into the pool and unused (unless there's something preventing the chunks from reaching Node's socket layer, such as AWS lambda freezing the runtime but at that point, this is sort of moot because the driver's process is frozen). Perhaps a rough outline of more-or-less the final product will look in node might help:

Sort of, here's a rough outline of what I imagine Node's implementation to look like:

// in our connection layer's `command()` method: async command() { try { ... } catch (error) { if (isTimeoutError(error)) { connection.lastChunkTime = now(); connection.state = 'pending response'; // if there is more than 3s between chunks, Nodejs will close this socket and error our connection for us connection.socketTimeoutMS = 3_000; } throw error; } } // in the connection pool async checkout() { // other steps already happened above, we have a connection: if (connection.state === 'pending response') { await awaitPendingRead(connection) } } async awaitPendingRead(connection, remainingTimeMS) { const remainingTime = now() - connection.lastChunkTime; // wait either 3s - total time waited so far, or remainingTimeMS const duration = Math.min(remainingTime, remainingTimeMS); // connection.responses.next() will resolve to a promise that returns a full wire protocol message, indicating we finished reading everything from the socket await Promise.race([sleep(duration), connection.responses.next()]); const timedOut = (now() - connection.lastChunkTime) > duration; if (timedOut) throw new Error('timed out'); // connection closes itself when socket timeout hits 3s - no need to close it here }

The three bullet points you note do not conflict with the algorithm, AFAICT

I mean, I agree to some extent. I think the implementation above satisfies the requirements here, but I wouldn't say that this implementation "implements" the algorithm (or if it does, it's a bit obfuscated by our connection layer and Node's connection APIs). That's why I'd prefer if we could rework the requirements to be a set of requirements that is socket API-agnostic, with a proposed algorithm that satisfies the requirements that drivers can implement if they want.

Sounds good, I've made updates to the phrasing to account for both push and pull socket i/o patterns.

baileympearson · 2025-05-02T15:58:46Z

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

+  connectionId: int64;
+
+  /**
+   *  The time it took to complete the pending read.


So long as data is still coming back from socket in intervals of <3s, it is possible for the same connection to require multiple checkout requests to fully exhaust. So - is this duration the total time it took to read all of the data off of the socket (now() - time of timeout) or the amount of time that the checkout request waited on the final pending read wait?

(same comment for logging events)

I would anticipate this duration to be within the context of ConnectionPendingResponseStarted, i.e. 1 call to await_pending_response.

Agreed. Can we clarify that in the description of duration? We can take inspiration from the definitions of duration for checkout failed and checkout succeeded events. Ex:

/** * The time it took to establish the connection. * In accordance with the definition of establishment of a connection * specified by `ConnectionPoolOptions.maxConnecting`, * it is the time elapsed between emitting a `ConnectionCreatedEvent` * and emitting this event as part of the same checking out. * * Naturally, when establishing a connection is part of checking out, * this duration is not greater than * `ConnectionCheckedOutEvent`/`ConnectionCheckOutFailedEvent.duration`. * * A driver MAY choose the type idiomatic to the driver. * If the type chosen does not convey units, e.g., `int64`, * then the driver MAY include units in the name, e.g., `durationMS`. */ duration: Duration;

So, maybe something like:

/** * The time it took to complete the pending read. * This duration is defined as the time elapsed between emitting a `PendingResponseStarted` event * and emitting this event as part of the same checking out. * * A driver MAY choose the type idiomatic to the driver. * If the type chosen does not convey units, e.g., `int64`, * then the driver MAY include units in the name, e.g., `durationMS`. */ duration: Duration;

(same comment for other definitions of duration in this PR).

baileympearson · 2025-05-02T15:59:24Z

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

+   */
+  connectionId: int64;
+
+  /**


Do you think it would be valuable to include a duration here as well, indicating how long the request waited for the pending read before failing?

(same comment for logging events)

I do think this is a good idea, this could highlight the case where you are trickling 1 byte aliveness checks but the response continues to time out while attempting to discard the input TCP buffer. Good call.

If we're in agreement that his seems valuable, can you make this change?

This change was made in 9500fd5

baileympearson · 2025-05-02T16:02:49Z

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

+    `ConnectionPendingResponseFailed` events.
+3. Instantiate a connection pool using the mock listener’s address, ensuring readiness without error. Attach the event
+    monitor to observe the connection’s state.
+4. Check out a connection from the pool and initiate a read operation with an appropriate socket timeout (e.g, 10ms)


This comment is related to my other comment about a less socket-api specific implementation. Is it possible to write these tests in a way that doesn't require explicit use of a read API? Node's connection layer doesn't expose a read method method, we only expose command() which performs write+read on the underlying socket.

So Node only has access to a round-trip API? Even in the non-public API? Could you not just discard the write half in the mock listener?

I interpreted "mock listener" as "mock server" but reading over this test more closely, that doesn't seem to be what you're asking for. Are you asking for some way of stubbing a socket and pushing chunks into the sockets buffer, instead of a mock server that the driver opens real TCP sockets to? That's possible in Node but I'd check with other drivers (I don't know if something like this exists yet in the specs, it may not be possible in other drivers).

Regardless, I'm not sure if these tests would work for the Node implementation I mentioned here

Yeah, the word "mock" is redundant here. We just need a way to simulate the response portion of the round trip using a TCP listener. Do you have suggestions on how we can accommodate theses tests for Node? No other drivers indicated this would be an issue: https://mongodb.slack.com/archives/C72LB5RPV/p1746558337106509

baileympearson · 2025-05-02T16:07:10Z

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

+7. Verify that one event for each `ConnectionPendingResponseStarted` and `ConnectionPendingResponseFailed` was emitted.
+    Also verify that the fields were correctly set for each event.
+
+#### Connection Aliveness Check Succeeds


Can we add a test that demonstrates that multiple aliveness checks might be required to fully read the response from the socket? I'm imagining the mock server emitting chunks of data every second for longer than 6s (2 * the static timeout). Each checkout should fail, but we'll continue to read

It’s unclear to me what the goal of this would be. Are you just wanting to make sure the driver does not pre-maturely close the connection if the aliveness check succeeds? We could use event monitoring for that instead.

Yes - I want a test somewhere that demonstrates that drivers might need to span multiple checkout + pending responses, and that that process can take longer than the static timeout, before reading the full response from the connection.

I suggest we defer this to the unified spec test and not further complicate the prose aliveness checks. Validating that a successful aliveness check does not result in a closed connection would imply that a subsequent check out would either perform an aliveness check or continue attempting to drain the buffer. LMK what you think.

baileympearson · 2025-05-02T16:12:51Z

source/connection-monitoring-and-pooling/tests/logging/connection-logging.yml

+
+  - description: "force a pending response read, fail first try, succeed second try"
+    operations:
+      - name: createEntities


If possible, can we add a test that demonstrates that when the pending read checkout has no timeoutMS set, we use socket_timeout_ms (if it is <3s)?

Great catch! The Go Driver doesn’t support socket timeouts which is a technically deprecated option. Perhaps @ShaneHarvey can opine. If we decide to add this test would you mind implementing it since the Go Driver has no way of verifying.

alcaeus

Changes to the unified test format LGTM.

@prestonvasquez as per our conversation around where to add the missing event names in #1782, this schema version would be an ideal candidate as it already adds new events to the list.

baileympearson · 2025-05-05T20:23:14Z

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

+The next time the connection is checked out, the driver MUST attempt to read and discard the remaining response from the
+socket. The workflow for this is as follows:
+
+- The connection MUST persist the current time recorded immediately after the original socket timeout, and this


Okay, leaving this where it is works for me. Thanks!

baileympearson · 2025-05-05T20:39:53Z

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

+   */
+  connectionId: int64;
+
+  /**


If we're in agreement that his seems valuable, can you make this change?

baileympearson · 2025-05-05T20:43:27Z

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

+  connectionId: int64;
+
+  /**
+   *  The time it took to complete the pending read.


Agreed. Can we clarify that in the description of duration? We can take inspiration from the definitions of duration for checkout failed and checkout succeeded events. Ex:

/** * The time it took to establish the connection. * In accordance with the definition of establishment of a connection * specified by `ConnectionPoolOptions.maxConnecting`, * it is the time elapsed between emitting a `ConnectionCreatedEvent` * and emitting this event as part of the same checking out. * * Naturally, when establishing a connection is part of checking out, * this duration is not greater than * `ConnectionCheckedOutEvent`/`ConnectionCheckOutFailedEvent.duration`. * * A driver MAY choose the type idiomatic to the driver. * If the type chosen does not convey units, e.g., `int64`, * then the driver MAY include units in the name, e.g., `durationMS`. */ duration: Duration;

So, maybe something like:

/** * The time it took to complete the pending read. * This duration is defined as the time elapsed between emitting a `PendingResponseStarted` event * and emitting this event as part of the same checking out. * * A driver MAY choose the type idiomatic to the driver. * If the type chosen does not convey units, e.g., `int64`, * then the driver MAY include units in the name, e.g., `durationMS`. */ duration: Duration;

baileympearson · 2025-05-05T20:43:38Z

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

+  connectionId: int64;
+
+  /**
+   *  The time it took to complete the pending read.


(same comment for other definitions of duration in this PR).

baileympearson · 2025-05-05T20:53:35Z

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

@@ -576,7 +576,106 @@ other threads from checking out [Connections](#connection) while establishing a
 Before a given [Connection](#connection) is returned from checkOut, it must be marked as "in use", and the pool's
 availableConnectionCount MUST be decremented.

-```text
+If an operation times out the socket while awaiting a server response and CSOT is enabled and `maxTimeMS` was added to
+the command, the driver MUST mark the connection as "pending" and record the current time in a way that can be updated.


No, not exactly. Unless we explicitly disable this behavior, any data that arrives on the socket will actually be processed by the driver, even while the connection is checked into the pool and unused (unless there's something preventing the chunks from reaching Node's socket layer, such as AWS lambda freezing the runtime but at that point, this is sort of moot because the driver's process is frozen). Perhaps a rough outline of more-or-less the final product will look in node might help:

Sort of, here's a rough outline of what I imagine Node's implementation to look like:

// in our connection layer's `command()` method: async command() { try { ... } catch (error) { if (isTimeoutError(error)) { connection.lastChunkTime = now(); connection.state = 'pending response'; // if there is more than 3s between chunks, Nodejs will close this socket and error our connection for us connection.socketTimeoutMS = 3_000; } throw error; } } // in the connection pool async checkout() { // other steps already happened above, we have a connection: if (connection.state === 'pending response') { await awaitPendingRead(connection) } } async awaitPendingRead(connection, remainingTimeMS) { const remainingTime = now() - connection.lastChunkTime; // wait either 3s - total time waited so far, or remainingTimeMS const duration = Math.min(remainingTime, remainingTimeMS); // connection.responses.next() will resolve to a promise that returns a full wire protocol message, indicating we finished reading everything from the socket await Promise.race([sleep(duration), connection.responses.next()]); const timedOut = (now() - connection.lastChunkTime) > duration; if (timedOut) throw new Error('timed out'); // connection closes itself when socket timeout hits 3s - no need to close it here }

The three bullet points you note do not conflict with the algorithm, AFAICT

I mean, I agree to some extent. I think the implementation above satisfies the requirements here, but I wouldn't say that this implementation "implements" the algorithm (or if it does, it's a bit obfuscated by our connection layer and Node's connection APIs). That's why I'd prefer if we could rework the requirements to be a set of requirements that is socket API-agnostic, with a proposed algorithm that satisfies the requirements that drivers can implement if they want.

baileympearson · 2025-05-06T16:42:49Z

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

+    `ConnectionPendingResponseFailed` events.
+3. Instantiate a connection pool using the mock listener’s address, ensuring readiness without error. Attach the event
+    monitor to observe the connection’s state.
+4. Check out a connection from the pool and initiate a read operation with an appropriate socket timeout (e.g, 10ms)


I interpreted "mock listener" as "mock server" but reading over this test more closely, that doesn't seem to be what you're asking for. Are you asking for some way of stubbing a socket and pushing chunks into the sockets buffer, instead of a mock server that the driver opens real TCP sockets to? That's possible in Node but I'd check with other drivers (I don't know if something like this exists yet in the specs, it may not be possible in other drivers).

Regardless, I'm not sure if these tests would work for the Node implementation I mentioned here

baileympearson · 2025-05-06T16:43:56Z

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

+7. Verify that one event for each `ConnectionPendingResponseStarted` and `ConnectionPendingResponseFailed` was emitted.
+    Also verify that the fields were correctly set for each event.
+
+#### Connection Aliveness Check Succeeds


Yes - I want a test somewhere that demonstrates that drivers might need to span multiple checkout + pending responses, and that that process can take longer than the static timeout, before reading the full response from the connection.

baileympearson · 2025-05-06T16:47:04Z

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

+socket. The workflow for this is as follows:
+
+- The connection MUST persist the current time recorded immediately after the original socket timeout, and this
+    timestamp MUST be updated to the current time whenever any data is successfully read from the socket during a


Are we concerned specifically about a case where the socket timeout beats maxTimeMS and the operation succeeds server-side but the connection is still put into a "pending response” state?

Yeah - like a network delay that slows down the response from the server initially. There wouldn't be anything that ends the operation server side in that scenario

ShaneHarvey · 2025-05-06T20:26:05Z

source/client-side-operations-timeout/tests/pending-response.yml

+        object: *database
+        arguments:
+          command:
+            ping: 1


The UTR runCommand operation requires the commandName: "ping" field:
https://github.com/mongodb/specifications/blob/30d15e0600a798834fb40d36eb468ccf9c49bc04/source/unified-test-format/unified-test-format.md#runcommand

ShaneHarvey · 2025-05-06T21:16:42Z

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

+socket. The workflow for this is as follows:
+
+- The connection MUST persist the current time recorded immediately after the original socket timeout, and this
+    timestamp MUST be updated to the current time whenever any data is successfully read from the socket during a


Yes this is a good call out. If moreToCome is present on the response, we should keep reading the connection until we get a response with moreToCome:false or the timeout expires.

prestonvasquez · 2025-05-09T20:13:08Z

source/client-side-operations-timeout/tests/pending-response.yml

+          - connectionCheckedInEvent: {} # Second find succeeds.  
+    # If the connection is closed server-side while draining the response, the 
+    # driver must close the connection.
+  - description: "connection closed server-side while draining response"


This seems to be a sufficient check that if the awaitPendingResponse function fails with a non-timeout error the connection should be closed.

ShaneHarvey · 2025-05-20T20:57:51Z

source/client-side-operations-timeout/tests/pending-response.yml

+          timeoutMS: 50
+          filter: {_id: 1}
+        expectError:
+          isTimeoutError: false


Shouldn't this error be considered retryable under the readable read/write specs?

CMAP only makes the pool-cleared error retryable at check-out. Since retryable reads occur at the operation layer and this particular network error happens at the connection pool layer (before a read command goes on the wire), I think we would have to extend the CMAP spec to say that network errors while checking out qualify as retryable.

Checkout errors should already be retryable. For example, a network error when establishing a new connection will cause an automatic retry.

The only error type we tag as retryable during checkOut is PoolClearedError. Nothing else in that layer is marked as retryable, which is why the test in question passes in the Go Driver. Am I missing something in the CMAP spec?

Yes that is a bug in the Go driver, see https://jira.mongodb.org/browse/DRIVERS-746

And the retryable writes spec:

When the driver encounters a network error establishing an initial connection to a server, it MUST add a RetryableWriteError label to that error if the MongoClient performing the operation has the retryWrites configuration option set to true.

https://github.com/mongodb/specifications/blob/master/source/retryable-writes/retryable-writes.md#retryablewriteerror-labels

This isn't a network error that occurs during a handshake, it's a network error encountered when trying to drain data from an established connection.

Correct but my point is that it is the same case in spirit. We can't introduce this new error mode without making it retrtyable.

I've updated the retryable reads and writes specifications to retry for network errors when checking out a connection.

…rror on conn c/o

ShaneHarvey · 2025-06-05T19:57:05Z

source/retryable-writes/retryable-writes.md

@@ -176,6 +176,9 @@ The RetryableWriteError label might be added to an error in a variety of ways:
    RetryableWriteError label to that error if the MongoClient performing the operation has the retryWrites
    configuration option set to true.

+- When the driver encounters a network error checking out a connection, it MUST add a RetryableWriteError label to that 
+    error if the MongoClient performing the operation has the retryWrites configuration option set to true.


We should mention a specific case of failing to read a pending response here.

ShaneHarvey · 2025-06-05T19:57:48Z

source/retryable-reads/retryable-reads.md

- Any of the above retryable errors that occur during a connection handshake (including the authentication step). For
-    example, a network error or ShutdownInProgress error encountered when running the hello or saslContinue commands.
+- Any of the above retryable errors that occur during a connection handshake (including the authentication step) or
+    connection checkout. For example, a network error or ShutdownInProgress error encountered when running the hello or


prestonvasquez added 2 commits October 14, 2024 15:06

DRIVERS-2884 Add connection churn spec tests

0f12706

DRIVERS-2884 Update json

fe18120

prestonvasquez requested a review from ShaneHarvey October 14, 2024 21:13

ShaneHarvey reviewed Oct 15, 2024

View reviewed changes

source/client-side-operations-timeout/tests/connection-churn.yml Outdated Show resolved Hide resolved

source/client-side-operations-timeout/tests/connection-churn.yml Outdated Show resolved Hide resolved

prestonvasquez requested a review from ShaneHarvey October 21, 2024 18:15

prestonvasquez added 7 commits October 30, 2024 15:59

DRIVERS-2884 Clean up spec tests

05cc88b

Update CMAP to include foreground read

98c2a73

Update changelog

4827995

Add justification for CMAP update

234b729

Remove unecessary example

ccfbcf1

Use consistent keys

fed567b

Update timeouts

8840be4

ShaneHarvey requested changes Apr 17, 2025

View reviewed changes

prestonvasquez added 15 commits April 21, 2025 18:11

DRIVERS-2884 Resolve merge conflicts

c1bee3b

DRIVERS-2884 Update pending response unified spec tests

c0e5aee

DRIVERS-2884 Add UML and update wording

dde9e22

DRIVERS-2884 Remove uneeded text from code snippet

5e0305a

DRIVERS-2884 Add prose tests

496724c

DRIVERS-2884 Clean up presentation

258edf8

DRIVERS-2884 Add logs and events

d217d10

DRIVERS-2884 Add log part

cc8aec0

DRIVERS-2884 Add Q&A section

3d98039

DRIVERS-2884 Add changelog

07e75bd

DRIVERS-2884 Fix Markdown failures

8d9e71b

DRIVERS-2884 Update schema

5c68f77

DRIVERS-2884 Update schema w/ new connection events

e2653cb

DRIVERS-2884 Remove additional properties

00aa620

DRIVERS-2884 Remove ignoring extra events

b29d6cc

prestonvasquez marked this pull request as ready for review April 25, 2025 21:36

prestonvasquez requested a review from a team as a code owner April 25, 2025 21:36

codeowners-service-app bot requested a review from qingyang-hu May 2, 2025 07:53

baileympearson requested changes May 2, 2025

View reviewed changes

alcaeus approved these changes May 5, 2025

View reviewed changes

prestonvasquez added 4 commits May 5, 2025 10:15

DRIVERS-2884 Add pending response state

9500fd5

DRIVERS-2884 Move logging tests to csot-specific file

5f3726b

DRIVERS-2884 Generate connection-logging-csot.json

d286786

DRIVERS-2884 Fix bug; add test super section

9c5b33a

prestonvasquez requested a review from baileympearson May 5, 2025 19:34

baileympearson requested changes May 6, 2025

View reviewed changes

ShaneHarvey reviewed May 6, 2025

View reviewed changes

prestonvasquez removed the request for review from qingyang-hu May 6, 2025 23:28

prestonvasquez added 5 commits May 8, 2025 10:55

DRIVERS-2884 Add commandName: ping

7bd5c00

DRIVERS-2884 Clarify behavior for exhaust cursors

cc9ec5c

DRIVERS-2884 Account for both pull and push i/o patterns

a397306

DRIVERS-2884 Update duration commentary

ef75645

DRIVERS-2884 Ensure all branches are tested

b5c1202

prestonvasquez commented May 9, 2025

View reviewed changes

DRIVERS-2884 Make Q&A read/receive agnostic

c785d0a

prestonvasquez requested review from ShaneHarvey and baileympearson May 9, 2025 20:29

ShaneHarvey requested changes May 20, 2025

View reviewed changes

prestonvasquez requested a review from ShaneHarvey May 20, 2025 22:25

DRIVERS-2884 Update retryable reads and writes to retry for network e…

1097f63

…rror on conn c/o

prestonvasquez requested a review from a team as a code owner May 28, 2025 22:10

prestonvasquez requested review from isabelatkinson and removed request for a team May 28, 2025 22:10

DRIVERS-2884 Update 1.24 with open/close schema udpates

49b5508

ShaneHarvey requested changes Jun 5, 2025

View reviewed changes

DRIVERS-2884 Give pending response examplesin retryable r/w specs

fe79807

prestonvasquez requested a review from ShaneHarvey June 5, 2025 20:49


		#### Connection Aliveness Check Fails

		1. Initialize a mock TCP listener to simulate the server-side behavior. The listener should write at least 5 bytes to

DRIVERS-2884 Avoid connection churn when operations timeout #1675

Are you sure you want to change the base?

DRIVERS-2884 Avoid connection churn when operations timeout #1675

Uh oh!

Conversation

prestonvasquez commented Oct 14, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prestonvasquez May 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prestonvasquez May 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alcaeus left a comment

Choose a reason for hiding this comment

prestonvasquez commented Oct 14, 2024 •

edited

Loading

prestonvasquez May 2, 2025 •

edited

Loading

prestonvasquez May 2, 2025 •

edited

Loading