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

Support for details in status payloads #11616

Closed
friscoMad opened this issue Oct 15, 2024 · 3 comments
Closed

Support for details in status payloads #11616

friscoMad opened this issue Oct 15, 2024 · 3 comments
Labels

Comments

@friscoMad
Copy link

I have not been able to find out a way to recover the details included in a server response status message, it seems that they are not included in grpc.io Status class and thus are not accessible from the StatusException thrown on server errors.
Is there a way to recover and access the details field from the client or using the details field is discouraged.
We were planning on using the recommended payload list from here: https://cloud.google.com/apis/design/errors#error_payloads but if the information can not be retrieved from the client it does not make sense to send.

For context we are using grpc-java 1.66 + grpc-kotlin 1.4.1 but the models are in the grpc-java side.

@kannanjgithub
Copy link
Contributor

There is a description field in Status and this is what is set by the gRPC server to add error details (example). Is your client not seeing this field set?

@ejona86
Copy link
Member

ejona86 commented Oct 16, 2024

I think @kannanjgithub intended to link to this example:

See also the gRPC guide that covers discusses the cross-language concepts.

@friscoMad
Copy link
Author

As I understand over the wire what it is sent is this model that include the details field with extra information about the error cause.
I was hoping to have access to that information from the client side, as far as I can tell that detail field is not included in the description as expected but is not stored in the io.grpc.Status object.

But after some more exploring it seems that details should be present in the metadata part of the exception and they were not there due to an unrelated bug.

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

No branches or pull requests

3 participants