Closed thundergolfer closed 5 months ago
Here is how error details should be encoded on the server-side (grpcio): https://github.com/grpc/grpc/blob/master/examples/python/errors/server.py
And here is an example of how you can read errors on the client-side (grpclib): https://grpclib.readthedocs.io/en/latest/errors.html#error-details
You don't have to encode/decode errors details manually and put them into trailers, this should be done automatically by corresponding libraries.
Also grpc-status-details-bin
metadata is not our invention, it is kinda part of the protocol. And grpcio
has the same constant in their codebase and looks like that it is also private: grpcio_status/grpc_status/_common.py#L20
You can create this constant in your codebase if you want, its value is not going to change, no need to import it from somewhere. In grpclib we treat this constant as an implementation detail, user should not deal with it so it shouldn't be a part of the public API.
Do you really need this shim? If yes then please explain why existing functionality is not enough.
Thank you for the response. We're using ServicerContext.abort
which is possibly why we can't take advantage of the existing mechanism provided by then library. I'll look into this further 👍.
Happy to close this to reduce clutter 🙂
We use
grpclib
in our Python client butgrpcio
in a server. In order for GRPC error details to propagate correctly we need this shim:The main problem with this shim in my opinion is the dependence on a private constant. It'd be good if
grpclib
library consumer could depend on the changing of this constant's value being reflected in semver.