Context

When the Go Driver is set to read server responses in the background after an operation timeout (see GODRIVER-3172), it still marks the session as "dirty" and discards it, leaving it to time out on the server. The rationale for that is that server sessions are not safe for concurrent use, so when there's a timeout, we don't know if the command is still running on the server, using that session. However, if we successfully wait for a server reply, we do know that the command finished and the session is no longer being used. We should wait to mark the session as "dirty" in the Go Driver until after the "background read" completes, and only mark it "dirty" if the "background read" also times out.

Detailed rationale for discarding sessions after a network error:

From SPEC-1159:

When a network error occurs while drivers are waiting for a response from the server, the operation continues to run on the server. However, the current sessions spec permits drivers to return the ServerSession of such operations to the pool when this happens. This is erroneous, because it means that the ServerSession may be reused by an unrelated subsequent operation, which violates the principle that a session "represents a set of sequential operations executed by an application that are related in some way". If this situation occurs, and an operator runs killSessions intending to kill just one of these operations, the other will also be inadvertently killed.

From the sessions spec:

When a network error is encountered when executing an operation with a ClientSession, the operation may be left running on the server. Re-using this ServerSession can lead to parallel operations which violates the rule that a session must be used sequentially. This results in multiple problems:

1. killSessions to end an earlier operation would surprisingly also end a later operation.
2. An otherwise unrelated operation that just happens to use that same server session will potentially block waiting for the previous operation to complete. For example, a transactional write will block a subsequent transactional write.

Definition of done

What must be done to consider the task complete?

Pitfalls

• The proposed behavior deviates from the behavior specified in the Sessions Spec. The more correct approach is to add the proposed behavior to the CSOT and Sessions specifications.