Current behavior

ConnectionPool.createConnection copies the pool generation into the connection options when the attempt starts. The success path then checks only that the pool state is ready. clear() increments the generation and pauses a non-load-balanced pool. ready() sets the pool ready again without moving the generation back. A handshake that was in flight across that sequence is checked out, or pushed into the available list, with the pre-clear generation. The pool spec does not allow a checkout to use a retired generation. The available-connection path already destroys perished sockets. The in-flight success path does not. Failing the waiter with PoolClearedError is the wrong outcome once the pool is ready, because the operation is not guaranteed to retry. processWaitQueue also returns immediately when called re-entrantly, so a clear() during a pass never rejects the waiters still queued.

Expected behavior

The retired socket is closed with reason stale. The waiter stays queued and is given a connection at the current generation. A clear() that interrupts a pass still rejects queued waiters with PoolClearedError once that pass returns, and no new handshake is started while the pool is paused.

Scope

src/cmap/connection_pool.ts. Present on main for any topology that uses ConnectionPool.clear(). Not specific to a server version.

Pull request

PR 5105