Goal: define a resource connecting to a remote gRPC service using reflection
Steps: configured a resource connecting on my remote host on port 443 and relying on a bearer token, and selected "Connect to gRPC using Server Reflection", then enabled "Use SSL/TLS"
Details: while "Test connection" works well, when I try to use the resource in an app, I get the following error:
However, the messages and types are available through the reflection service:
grpcurl -H 'authorization: Bearer *******β ********:443 describe .example.v1.public.users.User
example.v1.public.users.User is a message:
message User {
β¦
.example.v1.common.Gender gender = 6;
β¦
}
grpcurl -H 'authorization: Bearer ********β ********:443 describe .example.v1.common.Gender
example.v1.common.Gender is an enum:
enum Gender {
UNSPECIFIED = 0;
FEMALE = 1;
MALE = 2;
NON_BINARY = 3;
}
I tried to look at the documentation to understand if there was some kind of limitations on reflection, but didnβt find anything that seemed relevant.
Is this something thatβs supposed to be supported out-of-the-box? Did I missed something obvious here?
Thanks! Our team is still looking into this. If you can share your proto files with me, that could help us research. Either way, I'll post here with any more updates
We immediately get gRPC reflection type errors in the retool UI:
Error: no such Type or Enum β.commonβ.BillingDetails in Type .admin.CustomerData
Note: no server side errors occur during this test and similar to the original poster here, we can also successfully grpcurl. Retool gRPC "test connection" is also successful.
Found a similar issue here exhibited in the postman app. and the fix
Our team has not been able to consistently reproduce this error, which is why we haven't had many updates yet We were hoping to get more proto files from customers to continue testing. I can take another look at try to reproduce this error.
This extra context is helpful still! I will share it with the engineering team that owns this bug
This sample project here, as provided by the postman users, should help with reproducing the problem. It has multiple imports (more than 2) in the API proto.
Thanks for the extra context in office hours today! For a status update, I spent a couple hours with my team on this today, but we still need to get a minimal repro over to the team that can work on a fix. I will keep you updated with our progress - thanks for your patience and for offering to work with us on this