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

[ioext]

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

[cmgsj]

I am having the same issue, and also with grpcurl

[antonprokopovich]

Are there any updates on this? I'm facing the same issue when trying to connect with -plaintext option. I'm able to connect when I replace it with -insecure option but then some of the requests to server fail

[antonprokopovich]

I was able to resolve it by omitting the -plaintext option and passing the -cacert option followed by path to the CA certificate file

[venkad-intc]

I am facing the same issue. It works fine with grpcurl but not with grpcui. Any update?

[jhump]

@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.