Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server Side Error Reports #349

Open
matthewberends opened this issue Feb 14, 2024 · 0 comments
Open

Server Side Error Reports #349

matthewberends opened this issue Feb 14, 2024 · 0 comments
Labels

Comments

@matthewberends
Copy link

Describe the question
We use bugsnag to report any crashes that occur. Bugsnag uses SASL reports to automatically report process crashes. However with elixir-grpc they do not get reported.

We currently have to maintain a fork of elixir-grpc which will re-raise any errors that occur so that the error reports are created and thus reported to bugsnag.

For example in cowboy/handler.ex:

# unknown error raised from rpc
def info({:EXIT, pid, {:handle_error, e}}, req, _state = %{pid: pid}) do
  error = %RPCError{status: GRPC.Status.unknown(), message: "Internal Server Error"}
  trailers = HTTP2.server_trailers(error.status, error.message)
  exit_handler(pid, :error)
  req = send_error_trailers(req, trailers)
  error = HandlerError.exception(req: req, kind: e.kind, reason: e.reason, stack: e.stack)
  HandlerError.reraise(error)
end

as opposed to

def info({:EXIT, pid, {:handle_error, _kind}}, req, state = %{pid: pid}) do
  error = %RPCError{status: GRPC.Status.unknown(), message: "Internal Server Error"}
  trailers = HTTP2.server_trailers(error.status, error.message)
  exit_handler(pid, :error)
  req = send_error_trailers(req, trailers)
  {:stop, req, state}
end

This is our only difference in our fork from the upstream and would love to have services use the upstream directly. We attempted to mimic this behaviour using a server interceptor. This partially works as we can capture any errors that happen in our server implementations, but any errors that occur while trying to send the actually message (network, protobuf encoding) are not available to interceptors as interceptors are invoked before hand.

Are there any recommendations on how to handle this?

One potential solution to this could be to support a callback in the error handling code that users could set to allow some additional flexibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant