PinnedConnectionTaskExecutor::_doNetworking holds the PinnedConnectionTaskExecutor::_mutex while calling _ensureStream, which calls into ConnectionPool::lease and acquires the ConnectionPool::_mutex.

ConnectionPool::SpecificPool::finishRefresh is called while holding the ConnectionPool::_mutex, and in turn calls ConnectionPool::SpecificPool::processFailure. This function readies promises for pending requests. Readying such a promise can result in a thenRunOn/schedule call on any ExecutorFuture chained to the promise. Because PinnedConnectionTaskExecutor uses a NetworkInterfaceThreadPool for the search subsystem, we can try to run tasks inline with the schedule call when we're on the networking reactor, as we are when running finishRefresh for the connection pool. If one of the scheduled tasks is PinnedConnectionTaskExecutor::_doNetworking, we can end up acquiring the PinnedConnectionTaskExecutor::_mutex while holding the ConnectionPool::_mutex.

This is a potential deadlock and should be fixed. But, we have never seen the deadlock in the wild, only the inversion found by TSAN.