Handling AsyncConnectionPool._attempt_to_acquire_connection returning false?

[robo-corg]

I was reading the code for AsyncConnectionPool to see if there were ways to tweak httpx so I can recover faster from network blips from another service I am calling. Looking at the _attempt_to_acquire_connection implementation and I see it will bail out under various conditions but there doesn't seem to be anything that will retry getting a connection for a given status.

It looks like the lock might protect some cases but its hard to understand if this is sufficient. If it is why have the waiting/ordering check?

From my reading of the code if multiple _request ever get queued up with no connection only one will get a connection and the rest will get PoolTimeouts.

There seems like there is a similar issue with _max_connections being hit.

I can try to open a PR for this though I don't really have a good repro for any bug. I would the correct behavior here would be to trust the fairness of the _pool_lock if we can. It also seems like there needs to be some other async event that fires that retries _requests where _attempt_to_acquire_connection returned false though.

[TayfurYldz]

The pool implementation has changed substantially since the code this question refers to, and the current design does have the missing wake-up/reassignment point.

There is no longer an _attempt_to_acquire_connection() path where each waiter independently tries once and then has no event to retry. Requests are represented as queued AsyncPoolRequest objects. Whenever a request is added, removed, or a response is closed, the pool runs _assign_requests_to_connections() under its synchronization lock.

That method iterates all queued requests and, for each origin, either:

1. assigns an available existing connection,
2. creates a connection when below max_connections, or
3. evicts an idle connection and creates one for the queued request.

Each AsyncPoolRequest has an event; assign_to_connection() sets the assignment and wakes the waiter. When a response closes, the pool removes that completed request and immediately runs assignment again, so released capacity is offered to the remaining queue.

There is also a deliberate race fallback: if a connection looked available during assignment but handle_async_request() raises ConnectionNotAvailable, the request clears that assignment and loops through pool assignment again.

So the fairness question today is mostly about queue ordering/policy rather than “only one waiter ever gets a connection.” The current queued_requests list preserves the pool request order, and capacity release explicitly triggers another assignment pass. If you're debugging recovery from a network blip on current httpcore, I'd inspect whether connections are transitioning to closed/expired/idle correctly; a request remaining queued indefinitely despite released capacity would now indicate stale connection state rather than the old one-shot acquisition design.