You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
What did you do?
We have a grpc bidi streaming handler that we serve via the server's experimental ServeHTTP method. We've found that when a server streaming request comes in, that does not send its first request body longer than the http server's ReadTimeout, that the context is not closed.
What did you expect to see?
For the context to be closed.
What did you see instead?
That operations using that context block forever until we do a read on the body.
I believe this hasn't really come up in practice because it's quite odd to do anything with a request context prior to reading the body. However, in this bidirectional call, it's actually the server that sends the first message (response) and then the client sends the second message in response to the server (a flipping of the client server relationship if you will). We can certainly work around this but it took a very long time to debug why we never saw any cancelation/timeouts happen until our first server write happened that ultimately causes a client side write and then a server side read (which is long dead).
The text was updated successfully, but these errors were encountered:
This was further complicated by us never seeing this issue in practice until golang/net@a870f35 was committed which started to break things. Prior to that point, we could read freely, even if we were wrong about that assumption. It would seem better that in addition to closing the response body reader, that the request context also closes since this context may be used in other places during the request and functions similarly for timing out / canceling the request all together if a body has not been read.