Calling client.AllExtensionNumbersForType when no extensions exist returns an error

[nihar-aalyria]

Overview

I have a grpcreflect.Client on which I am calling AllExtensionNumbersForType(typeName). The type on which I am calling it refers to a very simple proto, resembling:

package foo;

message Bar {
  optional int baz = 1;

  extensions 100 to max;
}

No extensions to Bar currently exist. Strangely, calling AllExtensionNumbersForType("foo.Bar") is returning an error.

Hypothesis

I wonder if part of the issue could be doSendLocked()'s handling of io.EOF errors. This function calls cr.stream.Recv(), which calls refv1alpha.ServerReflection_ServerReflectionInfoClient.Recv(), which calls grpc.ClientStream.RecvMsg(). According to the comments for grpc.ClientStream.RecvMsg(), when a stream terminates normally, an error of io.EOF is returned.

So, I wonder if there needs to be any special handling in doSendLocked() for this case where no extensions exist. In this case, cr.stream.Recv() is expected to return io.EOF and this does not indicate an error but rather the end of an empty stream. My intuition would be that doSendLocked() returns an empty response and a nil error, instead of the current behavior of returning a nil response and the error.

Apologies if I've misunderstood -- definitely open to suggestions and discussion. Thank you!

[jhump]

@nihar-aalyria, I'm afraid EOF is not the issue. If that is what you are seeing, then this is an actual error. The way the server is supposed to reply is to send a response message in reply to the request for extension numbers. The reflection protocol is a bidi stream, so the client sends requests as individual messages on the stream and then, in the same order as requests were sent, the server sends response messages, in one to one correspondence to the request messages.

If you have not confirmed that the server is sending an EOF, then I suspect that the issue is that the server is actually sending back an error. In responding to an "all extension numbers" request, the server can send back either an "all extension numbers" reply or an error reply.

It would be easier to hypothesize on what is happening if you include some details on the error you are seeing -- like the actual error code and message. It might also be good to include details on the server, particularl what language is it written in and (if available) what version of the relevant gRPC runtime library it is using.

[nihar-aalyria]

Thank you for the quick reply, and apologies for the late response! I'll look into the error code and message, and re-open this issue if I have further details. Thanks!