grpc.Server with http.Server + TLS returns http2.errClientDisconnected, on stream cancellation from context cancel

[gyuho]

What version of gRPC are you using?

v1.7.5

What version of Go are you using (go version)?

Go 1.9.2

What operating system (Linux, Windows, …) and version?

Linux

What did you do?

Set up etcd with TLS, spawn a gRPC stream (watch API), and cancel the gRPC stream.

What did you expect to see?

Without TLS, pb.Watch_WatchServer.(grpc.ServerStream).Recv() returns "rpc error: code = Canceled desc = context canceled" on client-side stream cancellation.

With TLS, pb.Watch_WatchServer.(grpc.ServerStream).Recv() returns "rpc error: code = Unavailable desc = client disconnected" on client-side stream cancellation. And this is from golang.org/x/net/http2.errClientDisconnected.

What did you see instead?

We expect the same error with TLS enabled: "rpc error: code = Canceled desc = context canceled".

Only difference is that we wrap TLS-enabled gRPC server with http.Server while non-TLS gRPC server is called with grpc.Server.Serve(net.Listener).

For now, we worked around with manual error parsing etcd-io/etcd#9178.

Is this expected?

Thanks!

/cc @xiang90

[menghanl]

There are two different server transport in gRPC right now. A grpc.Server use the http2 implementation we implemented, while the handler server uses the http2 implementation in x/net/http2 package.

Client side cancellation will eventually result in a RST_STREAM to the server side. x/net/http2 package handles this and returns errClientDisconnected.
While in the gRPC http2 implementation, the context in the transport will be canceled, which results in the context canceled error you saw.

It seems to me that the difference is deep into the transport implementation. We cannot change x/net/http2's behavior, and our handling of RST_STREAM in our transport is also reasonable IMO.
I'm afraid there's not much we can do here.

[gyuho]

@menghanl Understood. Manual error parsing in client-side works for us.

Please feel free to close this.

Thanks.

[xiang90]

@menghanl

Can you report back to upstream then, or can you parse it at gRPC-go side and unify the errors?

We probably should try the best to provide a consistent error no matter what is the underlying transport.