0
votes

I have a server with gRPC stream. And after a client, who had previously subscribed on that stream, unsubscribing, I'm getting this error rpc error: code = Unavailable desc = transport is closing

After I've enabled more detailed logs, I saw this warning grpc: Server.Serve failed to create ServerTransport: connection error: desc = "transport: http2Server.HandleStreams failed to receive the preface from client: EOF" And I'm getting it a couple times per second. What can be a problem?

Client

stream, err := s.stream.GetStreamClient(metadata.AppendToOutgoingContext(ctx,"key","value"),&sub.StreamRequest{})
for {
   resp, err := stream.Recv()
   if err != nil {
       stream.CloseSend()
       return
}
....
}

Client can also call stream.CloseSend() after some timeout

Server

GetStreamClient(req *sub.StreamRequest, stream pb.StreamClient) error { 
for {
    err := stream.Send()
    if err != nil {
    //log error
    return
    }
  }
} 
2
How did you unsubscribe the client?Burak Serdar
@BurakSerdar I've tried if err :=stream.CloseSend(); err != nil { ... } And by cancelling context, i've passedYura Zherebukh
So the client is streaming data to server. Do not cancel the context.Burak Serdar
@BurakSerdar not quite. Client is making an gRPC call to the server, and server starts streaming to client. So client is subscribing. But when client wants to stop consuming messages from server, I'm getting that error on server's sideYura Zherebukh
Still, do not cancel the context.Burak Serdar

2 Answers

0
votes

Hi and welcome to StackOverflow.

I had this error many times and every time this error was about differences in proto generated in client and server

e.g: imagine you change your message from:

message example {
string var1 = 1;
string var2 = 2;
}

to :

message example{
string var1 = 1;
int64 var2 = 2;
}

and you forgot to regenerate clientside proto code. then the client wants to send var2 as string. but your server side expected as int64 then your server got panic error and will be closed.

0
votes

It's a bit late and quite a random shot: I was having a similar issue and it turned out that at some point I was infinitly looping internally and that kept the connection from getting actually closed.

I'm using another version of the grpc, so I can only guess here. But your code suggests that the server will only leave its infinite loop in case of an error. Have you checked that closing a stream actually leads to that error?