failed to resolve symbol

[ghost]

Hi, thanks for this project.

I have just installed from main, and I setup a minimal gRPC server.

When listing services, I have no issues:

grpcurl --plaintext localhost:8080 list
grpc.reflection.v1alpha.ServerReflection
user.UserServic

However, when I go to describe the service or list the method, I get:

grpcurl --plaintext localhost:8080 describe
grpc.reflection.v1alpha.ServerReflection is a service:
service ServerReflection {
  rpc ServerReflectionInfo ( stream .grpc.reflection.v1alpha.ServerReflectionRequest ) returns ( stream .grpc.reflection.v1alpha.ServerReflectionResponse );
}
Failed to resolve symbol "user.UserService": Symbol not found: user.UserService

or

grpcurl --plaintext localhost:8080 list user.UserService
Failed to list methods for service "user.UserService": Symbol not found: user.UserService

Perhaps I am missing something obvious.

[ghost]

Realizing that this is probably due to my usage of gogo/protobuf. Might not be compatible with reflection.

[Lucareful]

I hava the same problem. and i used gogo/protobuf , Is this problem solved now？Grateful

[jhump]

@Lucareful, @ghost: this is not a grpcurl issue as the problem is in the server, which does not correctly provide the reflection service due to the use of gogo. It's really an issue between gogoprotobuf and the reflection service implementation in the grpc-go repo. Details here: https://jbrandhorst.com/post/gogoproto/#reflection.

Unfortunately, as of a couple of weeks ago, the gogo project is no longer supported: gogo/protobuf#691 (comment)

You might see if Crowdstrike's csproto helps. It's a runtime indirection meant to provide better interop between gogo and the official v1 and v2 APIs ("github.com/golang/protobuf" and "google.golang.org/protobuf" respectively). Unfortunately, from what I understand of the underlying issue, it probably will not be able to help with getting the reflection service to work.

So another option (which is likely a much bigger effort to migrate, but is probably the right long-term path) is to migrate from gogo to vtprotobuf. It is supported and most importantly compatible with the official V2 protobuf runtime API (e.g. no more need to use a forked runtime). It provides many of the same advantages offered by gogo (mostly related to performance, especially for serialization/deserialization).