Fix fatal errors during request parsing #45
Conversation
| message=message, | ||
| ) | ||
| response_stream.close(error) | ||
| return |
There was a problem hiding this comment.
Might be easier and a bit more DRY to catch this exception and then send it to handle_result?
I also don't think it's accurate to always describe the error that could be happening here as a problem deserialising. "Exception calling application" as in handle_result is generic but probably more correct.
There was a problem hiding this comment.
We seem to be promising to return the same status error codes as the grpc library - this is enforced by the tests including the one I added.
I initially had something more like what you're describing, but we don't really have the correct inputs for handle_result available at this point, as well as the error code issue.
There was a problem hiding this comment.
Ha, I just noticed that the grpc library uses that message. Cool as it is then.
joechild-pace
force-pushed
the
fix-fatal-errors-during-request-parsing
branch
from
ee6f976
to
3ec3ba0
Compare
Any error during the parsing of request message for a unary request would be fatal, so we're catching it and returning a
GrpcErrorin line with thegrpclibrary.I've had to pin importlib-metadata due to a breaking release for python < 3.8. It looks like the issue will be fixed in the next version of
kombucelery/kombu#1601Annoyingly black was failing in CI due to a compatibility issue, so I've upgraded it. Sorry for the messy diff!