The asynchronous nature of Connection return via drop means that it's possible for one operation to finish, put its connection in the queue for processing, and then another operation starts before the queue is processed, sees an empty pool and spins up a new connection.

There are two problems with this:

• it's wasting resources, i.e. creating connections that don't need to exist, and slowing down operation time (waiting for a new connection to spin up is slower than reusing one from the pool)
• it complicates testing, as the new connection creation causes connectionReadyEvents to be emitted that don't match test expectations.

Ideally, an operation would block until the connection had been returned to the pool.  Because Rust doesn't have async drop, this would require either using a non-async mutex to protect the pool, which risks deadlock, or using some kind of manual lifecycle management for connections.