Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot list methods of a service and make requests #451

Closed
ttc0419 opened this issue Apr 7, 2024 · 1 comment · Fixed by #453
Closed

Cannot list methods of a service and make requests #451

ttc0419 opened this issue Apr 7, 2024 · 1 comment · Fixed by #453

Comments

@ttc0419
Copy link

ttc0419 commented Apr 7, 2024

When I list services, it works as intended:

[u]% grpcurl -plaintext 127.0.0.1:5443 list
grpc.reflection.v1.ServerReflection
grpc.reflection.v1alpha.ServerReflection
xxx.yyy

But when I was trying to list the methods:

[u]% grpcurl -plaintext 127.0.0.1:5443 list 'xxx.yyy'
Failed to list methods for service "xxx.yyy": Symbol not found: xxx.yyy
caused by: File not found: openapi/v3/annotations.proto

And it cannot invoke GRPCs as well:

[u]% grpcurl -d 'some json data' -plaintext 127.0.0.1:5443 '/xxx.yyy/Get'
Error invoking method "/xxx.yyy/Get": target server does not expose service "/xxx.yyy"
@jhump
Copy link
Contributor

jhump commented Apr 9, 2024

You can provide the schema yourself by providing proto source files are a compiled file descriptor set (using the -o argument of protoc or using buf build). But the issue here is that the reflection endpoint in the server is unable to provide the entire schema. As it states, it cannot provide a file descriptor for the import openapi/v3/annotations.proto.

This is an issue with how the Gnostic stuff is being used. For reflection to correctly work, the path you use in an import statement must match the path used when that file was compiled to generated Go code. This comment suggests you should be arranging your file system structure to so that the import statement is "openapiv3/annotations.proto" (no slash between "openapi" and "v3").

I can also look at updating my grpcreflect package to try to be lenient about this sort of thing. Generally, all of a file's imports must be present in order to properly construct a schema model for elements in that file. However, imports that only supply custom options could actually be omitted and the schema could still be constructed. The result is that any custom options would be uninterpreted, which would work for grpcurl and grpcui since they don't care about custom options (though it does mean that custom options would be absent when you try to describe an element with grpcurl).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants