Why doesn't HTTP2Connection.is_available check if _max_streams has been reached?

[ruanimal]

currently

    def is_available(self) -> bool:
        return (
            self._state != HTTPConnectionState.CLOSED
            and not self._connection_error
            and not self._used_all_stream_ids
            and not (
                self._h2_state.state_machine.state
                == h2.connection.ConnectionState.CLOSED
            )
        )

If _max_streams is reached, new requests will enter a waiting state.
However, in this case, the value of max_connections is usually not reached.
I think it would be better to create a new connection here.

[tayfuryldz]

I would not put _max_streams into is_available() as it stands.

The pool uses is_available() to answer a longer-lived question: "can this connection accept/reuse a request?" For HTTP/2, reaching the peer's current MAX_CONCURRENT_STREAMS is temporary backpressure, and HTTP2Connection already models that with _max_streams_semaphore. A stream completing releases a permit, so a request waiting there can proceed on the same multiplexed connection.

If is_available() returned false whenever all current stream permits were occupied, the pool could create additional TCP/TLS/H2 connections whenever there is a short burst above the peer's stream limit. That changes pooling semantics substantially and can defeat a server's intention to multiplex requests over a small number of connections.

There is also a synchronization problem: _max_streams is the negotiated limit, not "free stream slots". The actual occupancy is represented by the semaphore. Comparing request count to _max_streams outside the semaphore would duplicate capacity state and introduce a race between the pool's selection and HTTP2Connection.handle_async_request acquiring the permit.

So the current behavior is internally consistent: available H2 connection + no stream permit means wait for capacity. If the desired feature is "open another H2 connection rather than wait once a connection is stream-saturated", that should be an explicit pool policy/capacity signal, not a change that makes is_available() conflate temporary stream saturation with an unusable connection.

A useful benchmark/test for such a policy would need to show the tradeoff: latency improvement under a low remote MAX_CONCURRENT_STREAMS versus extra connection/TLS setup and server connection count.