HTTP2 GoAway frames don't seem to be handled gracefully in keepalive connections

[Tugzrida]

Using the below minimal example targeting an Nginx server configured with keepalive_time 30s;, the fourth request through the loop throws a RemoteProtocolError after Nginx sends a GoAway frame.

import httpx, time
c = httpx.Client(http2=True, limits=httpx.Limits(max_connections=100, max_keepalive_connections=20, keepalive_expiry=20))

while True:
    print(c.get('https://example.test'))
    time.sleep(10)

Looking at #733, I've narrowed this down to the fact that this seems to be occurring when stream_id and last_stream_id are equal, indeed if I patch that line to be stream_id >= last_stream_id, requests gracefully retry on a new connection.

I'm not very familiar with the internals of HTTP2 so I don't know if this is an appropriate fix for all situations, but it would be great if this could work as seamlessly as it does in HTTP/1.

[tayfuryldz]

The equality case in the report is significant, and the current code still uses stream_id > last_stream_id in both sync and async implementations.

For GOAWAY, last_stream_id is the highest stream the peer says it processed. A stream with an ID greater than that value is known not to have been processed, so httpcore can safely raise ConnectionNotAvailable and let the pool retry it on a new connection. A stream whose ID is equal to last_stream_id, however, may have been processed. Retrying it automatically is not generally safe: for a non-idempotent request that could duplicate an operation.

That means changing the comparison to >= would make the reproducer look seamless, but it changes retry safety. I would not make that change globally.

The more useful distinction is between the request that was already accepted on the old HTTP/2 connection and a subsequent request that the pool assigned to a connection after GOAWAY had arrived. Once ConnectionTerminated is observed, is_available() should prevent new work from being assigned there, while streams above the advertised last ID can be retried because the peer explicitly says it did not process them. The equal-ID stream should surface the termination unless httpcore has an independent idempotency/retry policy.

So I'd preserve > and write the regression around connection reuse after GOAWAY, rather than treating equality as “not processed.” That keeps graceful pool recovery without introducing an unsafe automatic retry for the last acknowledged stream.