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
What operating system (Linux, Windows, …) and version?
Linux
What did you do?
NOTE: Copied from an issue for the swift client since we don't know what is the correct behaviour: grpc/grpc-swift#1520
We use a server implemented with grpc-go This server may gracefully shutdown the connection before shutting down itself. In the repository of grpc-go it is documented that the server sends two GOAWAY frames to circumvent a http2 race condition:
'''
// A client can receive multiple GoAways from the server (see
// #1387). The idea is that the first
// GoAway will be sent with an ID of MaxInt32 and the second GoAway will be
// sent after an RTT delay with the ID of the last stream the server will
// process.
'''
The grpc-swift-client responds to both GOAWAY frames with GOAWAY frames which leads the grpc-go-server to crash. E.g. the client implementation of grpc-go checks for already received GOAWAY frames and their stream ids which prevents two following GOAWAY frames by the client (Implementation).
Since the behavior of the grpc-swift-client causes other servers to crash we expect grpc-swift to change the behavior.
To reproduce
Steps to reproduce the bug you've found:
Initiate connection
Make a bidirectional RPC to the server (grpc-go)
Invoke gracefullShutdown on the server
Clients sends two GOAWAY frames
Server crashes due to close of closed channel
We could reproduce the behaviour utilising the client from RouteGuide-Example and implementing a go-server using the example proto file.
What did you expect to see?
The server doesn't crash.
What did you see instead?
The server crashes due to closing a channel twice.
The text was updated successfully, but these errors were encountered:
What version of gRPC are you using?
google.golang.org/grpc v1.50.1
What version of Go are you using (
go version
)?go 1.19
What operating system (Linux, Windows, …) and version?
Linux
What did you do?
NOTE: Copied from an issue for the swift client since we don't know what is the correct behaviour: grpc/grpc-swift#1520
We use a server implemented with grpc-go This server may gracefully shutdown the connection before shutting down itself. In the repository of grpc-go it is documented that the server sends two GOAWAY frames to circumvent a http2 race condition:
'''
// A client can receive multiple GoAways from the server (see
// #1387). The idea is that the first
// GoAway will be sent with an ID of MaxInt32 and the second GoAway will be
// sent after an RTT delay with the ID of the last stream the server will
// process.
'''
The grpc-swift-client responds to both GOAWAY frames with GOAWAY frames which leads the grpc-go-server to crash. E.g. the client implementation of grpc-go checks for already received GOAWAY frames and their stream ids which prevents two following GOAWAY frames by the client (Implementation).
Since the behavior of the grpc-swift-client causes other servers to crash we expect grpc-swift to change the behavior.
To reproduce
Steps to reproduce the bug you've found:
We could reproduce the behaviour utilising the client from RouteGuide-Example and implementing a go-server using the example proto file.
What did you expect to see?
The server doesn't crash.
What did you see instead?
The server crashes due to closing a channel twice.
The text was updated successfully, but these errors were encountered: