Open asummers opened 4 years ago
Note that adding an interceptor with:
@impl GRPC.ServerInterceptor
@spec call(
GRPC.Server.rpc_req(),
GRPC.Server.Stream.t(),
GRPC.ServerInterceptor.next(),
GRPC.ServerInterceptor.options()
) :: GRPC.ServerInterceptor.rpc_return()
def call(request, stream, next, _options) do
try do
next.(request, stream)
rescue
exception in GRPC.RPCError ->
{:error, exception}
exception ->
reraise exception, __STACKTRACE__
end
end
into the interceptor list at the bottom restores what I believe to be the intended behavior, but this should not be necessary.
At first, exception is catched in the innermost layer. Now it's changed https://github.com/elixir-grpc/grpc/pull/96. The main reason is now we can support catching the exceptions in interceptors, which is more flexible and exceptions in interceptors are also handled. But yes, as you said, now interceptors may need to handle exceptions. I'm thinking maybe we can improve this by:
GRPC.RPCError
in the innermost layer.btw, I checked Plug code. It seems it also doesn't catch the exceptions in the innermost layer.
I think Plug has https://hexdocs.pm/plug/Plug.ErrorHandler.html. Your option 2 seems best.
@asummers @hkrutzer is this issue still relevant?
Describe the bug The type spec for the Server Interceptor
next
return type is:but when raising an error, e.g
the interceptor seems to be bypassed entirely and is never given the
{:error, exception}
tuple .To Reproduce Create an interceptor with the following
call/2
:create a protbuf call that does something like the following:
Make a call with e.g. grpcurl and notice that it responds appropriately:
But then notice the logs from the app only contain:
Expected behavior Exceptions are turned into errors centrally so that interceptors can avoid having to rescue, or requiring a "rescue interceptor" that does this for you. Things like the included Logger interceptor do not work appropriately without doing something like this.
Versions: