Open Skepfyr opened 3 years ago
Your speculation is correct. The solution for hyper to automatically retry these is a little harder to do.
Reason::NO_ERROR
, which can also be sent on a stream that was received, processed, and the rest of the body is no longer interesting.It would be possible at a layer above hyper (so, by the user, for instance) to use something like tower::retry
, to get it the request to retry if you know it will be safe to do so.
I can see why it might be impossible for hyper to retry the request automatically. However, as you say, the errors don't currently give the user enough information to know whether the request can be safely retried. How hard would it be to improve the error signalling to include that information?
I think the piece of information that the user is interested in is whether the requests may have reached the server, or if it definitely didn't. I don't think you can be more precise than that. A general "it's safe to retry that request" would be great but I'm not sure it's possible to determine between transient and more permanent connection issues.
Yea, I think we'd need to redesign the h2::Error
type some, so that it can include if it's a stream error, or a connection error (GOAWAY
). Then we'd be better equipped to answer that programmatically.
@seanmonstar Could you give pointers on how to redesign the h2::Error
? We encounter this behaviour in the wild and would like to fix it.
It's possible this is an
h2
issue but I don't know the crates well enough to know.If a GOAWAY is received while multiple requests are in flight some of them fail with the error:
I can reproduce this by running the following code:
I ran this against an nginx instance with the following config to force http2 and send a GOAWAY after every single request.
This program generates the logs (edit: I've added in the trace level logs too if they're useful trace.log):
Rampant speculation
My suspicion is that any stream after the final stream inidicated in the HTTP2 GOAWAY frame, that were spawned before hyper received the goaway, throw this error. I would expect hyper to retry them on a new connection, as it does for any connection spawned later on (I assume after the client has marked the old connection as closed).