search

grpc / grpc-web

gRPC for Web Clients
https://grpc.io
Apache License 2.0
8.6k stars 765 forks source link

Richer error model #736

Open smnbbrv opened 4 years ago

smnbbrv commented 4 years ago

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 commented 3 years ago

The original issue is at #399

dawsonc623 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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! :)