@ioext, @cmgsj, @antonprokopovich, @venkad-intc, the real root cause is an issue in your protos. The protobuf-go runtime cannot find the descriptor for a dependency, so it creates a placeholder file descriptor. The grpc-go reflection implementation then sends that placeholder file descriptor as part of a reflection response. The placeholder descriptor has this invalid syntax string, which causes the error.

If things worked fine with an earlier version of grpcurl or grpcui, it is because the missing dependency likely is just for custom options. The older versions of grpcurl and grpcui didn't use the protobuf-go's reflection capability, but instead an alternate implementation in github.com/jhump/protoreflect. This alternate implementation didn't validate the syntax string, so would have used the invalid (and empty) placeholder descriptor. The only way this can work and grpcurl/grpcui still be able to resolve the RPC schema is if the only thing in the dependency were custom options (which grpcurl/grpcui would see as unrecognized fields and ignore).

You can find more details in this grpc-go issue: grpc/grpc-go#6770.

While there are some fixes to the grpc-go and protobuf-go runtime, they would simply change the error message to something less confusing. The root issue is still that a file descriptor for a dependency cannot be resolved.

Most likely, the issue is that your sources are importing some vendored source of custom options (like from grpc-gateway, googleapis, protoc-gen-validate, protovalidate, etc) but using the "wrong" import path. The import statement must refer to the file using the same relative path that was used to compile that file in order for the descriptors to be properly discovered and linked. See this article for more details.

M1 grpcui -plaintext localhost:8023 Failed to compute set of methods to expose: proto: invalid syntax: "<unknown:0>" #279

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions