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

Richer error model #736

Open
smnbbrv opened this issue Feb 20, 2020 · 9 comments
Open

Richer error model #736

smnbbrv opened this issue Feb 20, 2020 · 9 comments

Comments

@smnbbrv
Copy link

smnbbrv commented Feb 20, 2020

The website https://grpc.io/docs/guides/error/ claims there is an open issue at grpc-web

This richer error model is already supported in the C++, Go, Java, Python, and Ruby libraries, and at least the grpc-web and Node.js libraries have open issues requesting it.

However I cannot find it. So, here it is :)

Are there plans to support it?

@Sharsie
Copy link

Sharsie commented Sep 17, 2021

The original issue is at #399

@dawsonc623
Copy link

I tried to go through the other issue, but it seems to be focused on the implementation details of a piece of this support. Is there a status or plan regarding exposing rich errors in a way users can get pretty easily? I introduced them to my services used in the back-end, but it would be nice to bubble useful information to the front-end for user errors.

@sampajano
Copy link
Collaborator

@dawsonc623 Thanks for reaching out!

Is there a status or plan regarding exposing rich errors in a way users can get pretty easily?

No, there isn't a current plan of improvement in this particular area :)

Do you have a specific requirement that "grpc-status-details-bin" (in #399) isn't able to satisfy?

Do you have a proposal on how the improvement can be? Thanks!

@dawsonc623
Copy link

Perhaps I am doing it wrong, but when I make a call that returns an error it comes back as a rejected promise without that information - I get an error object with the basic error information. I can see grpc-status-details-bin on the response, but I am not sure how to get at it to even start trying to process it. Is it supposed to be easily accessible?

@sampajano
Copy link
Collaborator

Aha! From the example given here, it was using the stream callback API rather than promise. Could you try if that work?

We can potentially explore how to make this information more accessible on the promise too as a follow up 😃

@dawsonc623
Copy link

So, I was trying to fiddle with this. The client I use does not return the same kind of object as that one, it seems (I am using the TypeScript generator). I do not have a stream API (no on method or anything), so I am not sure that solution works for me. For the time being, I just shoved some encoded information in the status message and decode it myself. It is ugly, but I am using a lot of time trying to figure out error handling versus actually working on the project. I hope to be able to use the richer error model eventually, but right now it does not seem possible.

@sampajano
Copy link
Collaborator

The client I use does not return the same kind of object as that one, it seems (I am using the TypeScript generator).

In order to use the ".on(..." callbacks you need to use the callback style API (not the Promise one):
https://github.com/grpc/grpc-web/blob/master/packages/grpc-web/index.d.ts#L6-L19

Which i think should give you an object in return, even if it's Typescript.

For the time being, I just shoved some encoded information in the status message and decode it myself. It is ugly, but I am using a lot of time trying to figure out error handling versus actually working on the project. I hope to be able to use the richer error model eventually, but right now it does not seem possible.

Yeah apologize for the inconvenience! Will track it as a potential improvement!

@dawsonc623
Copy link

Yeah apologize for the inconvenience! Will track it as a potential improvement!

No worries! This would be a great improvement. I found that the TypeScript support I am using looks to be a project built on gRPC web and not part of the core ecosystem. It seems they assumed this information would be there, too, so it was a bit confusing and time consuming to sort out what was happening. I am not sure what their implementation looks like at the moment, but given the data is not present in any of the objects I get back I assume they rely on the Promise API. For those of us using that project, we seem to be dead in the water with the richer error model.

Thanks for tracking potentially adding the data! Worst case, I suppose I can pivot from that other project if I need to, but I have spent too much time on this already. Time to get some actual features implemented!

@sampajano
Copy link
Collaborator

found that the TypeScript support I am using looks to be a project built on gRPC web and not part of the core ecosystem.

I am not sure what their implementation looks like at the moment, but given the data is not present in any of the objects I get back I assume they rely on the Promise API.

Oh i see.. Yeah maybe they're using the promise API, which doesn't provide the metadata. Maybe you can file a FR for them to move to a callback based API and provide them instead, if you care enough?

It seems they assumed this information would be there, too, so it was a bit confusing and time consuming to sort out what was happening.

Yeah i'm sorry that happened. We have documented this limitation of the Promise API, but yeah it would be ideal if that info is on Promise API also.

Thanks for tracking potentially adding the data! Worst case, I suppose I can pivot from that other project if I need to, but I have spent too much time on this already. Time to get some actual features implemented!

Yeah sure! You could also consider informing them to use the callback API too, which could provide the metadata if they choose to, if you care enough.. :)

In any case, good luck with your actual features! :)

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

No branches or pull requests

4 participants