-
Notifications
You must be signed in to change notification settings - Fork 764
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
Comments
The original issue is at #399 |
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. |
@dawsonc623 Thanks for reaching out!
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! |
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 |
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 😃 |
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 |
In order to use the ".on(..." callbacks you need to use the callback style API (not the Promise one): Which i think should give you an object in return, even if it's Typescript.
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 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! |
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?
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.
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! :) |
The website https://grpc.io/docs/guides/error/ claims there is an open issue at grpc-web
However I cannot find it. So, here it is :)
Are there plans to support it?
The text was updated successfully, but these errors were encountered: