Giters

deeplay-io / nice-grpc

A TypeScript gRPC library that is nice to you

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Access to error metadata?

vitalets opened this issue · comments

commented

Currently ClientError takes only code and details from original error.
But my server returns valuable info in error.metadata.
is it possible to access original error metadata?
Thanks!

commented

Error metadata is sent via trailers, which can be accessed by client using call options. See https://github.com/deeplay-io/nice-grpc/tree/master/packages/nice-grpc#metadata-1

commented

@aikoven Thanks for the info, I was not aware of trailers!
Now I see needed data in onTrailer handler.
Could you suggest an approach how can I catch all errors of generated client methods and attach particular headers to the thrown Error?

commented

btw, maybe just attach originalError to ClientError instance?

commented

Trailer metadata is purposefully detached from ClientError, but there is a way to achieve what you're proposing by extending ClientError and using a client middleware. For an example of this approach see https://github.com/deeplay-io/nice-grpc/tree/master/packages/nice-grpc-error-details/src/client

commented

Trailer metadata is purposefully detached from ClientError, but there is a way to achieve what you're proposing by extending ClientError and using a client middleware. For an example of this approach see https://github.com/deeplay-io/nice-grpc/tree/master/packages/nice-grpc-error-details/src/client

Thank you! I've come to the similar code. The only thing that confuses me - what if request contains it's own onTrailer handler? Looks like it will be overwritten..

commented

Good catch! Fixed in 2d781a4

commented

@aikoven btw, what's the purpose of detaching metadata from ClientError?

commented

Short answer is to keep the core as low-level as possible.

Some points:

  • Trailer metadata can be sent with OK response as well, not just with errors. So there must be a way to write it on the server / read on the client without involving ServerError / ClientError. Then, if there's such a way, it should be the only way — to keep the API simple.
  • Trailer metadata can potentially contain data unrelated to the error.
  • There's no single universal approach to "error metadata". You can use the whole trailer as the error metadata, or use the google's rich error model, or roll your own. That depends on the conventions in your team. If we add the whole trailer to the ClientError, then for example if someone uses the rich error model, they will have errors with both rich error details and that same details but in binary format.
commented

Thanks for explanation and awesome library!