With HTTP/2, when a server is performing graceful shutdown, it sends a GOAWAY frame to a client, if the client tries to start a new stream. During this shutdown, the server refuses new streams and will continue processing existing streams until they are complete (or until some timeout occurs).
With a connect-go client, this can result in errors like the following:
unavailable: http2: Transport: cannot retry err [http2: Transport received Server's graceful shutdown GOAWAY] after Request.Body was written; define Request.GetBody to avoid this error
PR #649 addresses the above issues when it comes to handling unary requests (unary and server-stream RPCs). But it's still a possible issue with streaming requests.
Implementing GetBody with a streaming request is more complicated because it will involve buffering some (likely small) amount of request data, as the client is uploading, which can then be "replayed" in the event of a transport-level retry and use of GetBody. This issue is to track the state of such a future enhancement.
With HTTP/2, when a server is performing graceful shutdown, it sends a
GOAWAYframe to a client, if the client tries to start a new stream. During this shutdown, the server refuses new streams and will continue processing existing streams until they are complete (or until some timeout occurs).With a connect-go client, this can result in errors like the following:
PR #649 addresses the above issues when it comes to handling unary requests (unary and server-stream RPCs). But it's still a possible issue with streaming requests.
Implementing
GetBodywith a streaming request is more complicated because it will involve buffering some (likely small) amount of request data, as the client is uploading, which can then be "replayed" in the event of a transport-level retry and use ofGetBody. This issue is to track the state of such a future enhancement.