gRPC resource reflection type resolution

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 in advance for any help :pray:

1 Like

does the name of that enum start with a . or is that a typeo?

It's not a typo, it's part of the server reflection response.

Hi @batou Our team is looking into this internally, so I'll keep you posted if I get any updates or if we have any follow up questions!

Is clicking "Test Connection" button on the resource successful or does that have an error as well?

Hi @Tess,

Thanks for the update!

Yes, I can confirm that the "Test Connection" works fine:

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

I am also experiencing this same issue when using GRPC Reflection.
Thanks!

Hey folks,

We are still looking into this. @keenan, @batou by any chance, are you using akka/scala?

I am not using either of those.

Thanks :+1:

Are you able to share your proto files with us for testing?

@Tess

I'm also facing this issue and struggling with it. Has there been any progress on this problem?

We are using connect-go and performing reflection. It works fine with Postman and BaseMachina.

No, not yet :disappointed: Are you able to share your proto files with us for testing?


​

The version of Java GRPC seems outdated. Maybe it is related to this. Also my connection using GPRC timeout frequently.

@Tess any news on this? We are experiencing this also. Go based gRPC backend.

Hi @pthmcable,

Unfortunately, no update yet. I added your +1 and will follow up if I hear anything!

@batou We are also experiencing this, it seems to be related to gRPC reflection with shared protos.

@Tess any updates on this? this post is coming up to the 1-year mark

cc @jmann

To provide more clarity on the issue, I’ve dug a little deeper on our side to see what cause the above error.

Currently our gRPC retool facing service proto has two shared protos it uses for messages:

import "packages/internal-service-client-a/client.proto";

import "packages/internal-service-client-b/client.proto";

We can successfully utilize the above imports to pull in messages as fields, etc and make successful calls from retool to this service.

If we modify the retool facing service proto to import from a 3rd shared proto:

import "packages/internal-service-client-a/client.proto";

import "packages/internal-service-client-b/client.proto";

import "packages/common-client/client.proto";

Message CustomerData {

…

optional common.BillingDetails billing_details = 100;

}

which has the following minimal content (just one message, no rpc declarations):

syntax = "proto3";

package common;

message BillingDetails {

string contract_id = 1;

string customer_id = 2;

…

}

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

Hi @travis_foyer,

Thanks for checking in on this topic!

Our team has not been able to consistently reproduce this error, which is why we haven't had many updates yet :disappointed: 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

Hi @Tess ,

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.

Hope this helps!

1 Like

Hi there,

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