Summary

Depending on the implementation details of the connection pool Background Thread and WaitQueue, it's possible for the sequence of operations described in pool-checkout-minPoolSize-connection-maxConnecting.yml to result in either 2 or 4 created connections.

In the Go driver, there is a race between checking-in a connection established by the background thread that maintains minPoolSize and a check-out requesting a new connection. As a result, it's possible for a checkOut request blocked on maxConnecting to trigger establishing a new connection before the connection created by the background thread is available in the pool.

Motivation

Who is the affected end user?

Drivers devs implementing maxConnecting and trying to run CMAP spec tests.

How does this affect the end user?

There is no known end user impact.

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

The described behavior currently happens reliably in the Go driver. The impact to other drivers is unknown, but it seems like most other drivers' connection pool implementations work with the existing test. The impact may increase as other drivers make connection pool implementation changes as part of CSOT.

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

_Minor annoyance at a log message? Performance concern? Outage/unavailability? The CMAP spec tests may fail. There is no known end user impact.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

Yes.