Summary

Add a reason for a connection pool Clear method. The included information should clarify why the method has been called, for example include Heartbeat exception.

Motivation

Who is the affected end user?

Drivers

How does this affect the end user?

-

How likely is it that this problem or use case will occur?

It's always reproducible in sharded transaction where pinning server is involved. Steps:

1. The valid server is pinned by the previous operation
2. Then heartbeat is failed, the pool is paused. The server is not unpinned because heartbeat doesn't participate in unpinning
3. The next operation in transaction sees the pinned server and doesn't select it again, then tries to acquire connection and sees pausable pool exception without a reason of why it has been triggered.

The same behavior where we use previously selected server happens in cursors. We pass the server that has been selected in the initial operation into cursor and don't select any other server for internal cursor operations like GetMore or KillCursor (regardless wire protocol)

If the problem does occur, what are the consequences and how severe are they?

The implementation of this ticket will allow easier diagnostic of why the paused pool exception has been triggered.

Is this issue urgent?

no

Is this ticket required by a downstream team?

no

Is this ticket only for tests?

no