context deadline can cause surprising errors about quic-go HOT 4 CLOSED

It looks like my particular issue may be a little different than described. I was definitely seeing "timeout: no recent network activity" in my logs, which is why I thought quic.IdleTimeoutError may be to blame.

However, it looks like the actual error that a client is much more likely to receive is an http3.Error with a code of H3_REQUEST_CANCELLED. With quic.IdleTimeoutError, my work-around was check for instances of net.Error where err.Timeout() returned true. But with this latest observation, I must put work-around code that is quite bespoke to this library to properly detect context-related errors. I suspect an appropriate improvement would not involve touching http3.Error but instead something else in the round-tripper so that it can correctly return context.Canceled or context.DeadlineExceeded when an http3.Error is triggered via the context.

from quic-go.

I'm not sure I understand under which condition exactly you expect the context cancelation error.

In general, an idle timeout can occur at any time during the handshake or the connection, if the other peer suddenly goes away without telling us. There's no context being canceled here, so we shouldn't return a context cancelation error.

Am I right to assume that you're setting the context on the http.Request, cancel that context, and now expect the error on RoundTripper.RoundTrip to be a context cancelation error? Is that what HTTP/2 does? Assuming that's the case, I agree that this would be the correct behavior, and we should make sure that HTTP/3 does the same (I haven't checked what it does right now).

from quic-go.

Am I right to assume that you're setting the context on the http.Request, cancel that context, and now expect the error on RoundTripper.RoundTrip to be a context cancelation error?

Yes. That is what the standard lib net/http stuff does, with the exception of the bug I linked above, where the dial operation (when no existing connection is in the pool) can instead return os. ErrDeadlineExceeded.

For the case of the error I'm seeing, I think the HTTP/3 round tripper implementation could examine the http.Error and the request's context and then massage the error to wrap the error and return something that is easier to inspect.

from quic-go.

Closing in favor of #4205.

from quic-go.