Errors shown as ErlangError instead of the specific error

[sezaru]

I don't know if this is expected since it is the first time I used Honeybadger, but most of the errors I'm receiving are encapsulated inside ErlangErrors. For example this one:

As you can see, two of the errors are actually Postgrex.Error errors but they are encapsulated inside an ErlangError for some reason. This gives me 2 problems since I lose the nice stack trace view (the whole stack trace is contained inside the message part of the error view page.

And way worse this makes Honeybadger combine errors that don't have anything to do with one another as the same error. You can see this happening in the above image since it combined 2 websocket :close errors with 2 Postgrex errors.

Is there some option to fix this or is this a bug? I'm using the latest version and I also have sasl enabled with the option config :logger, handle_sasl_reports: true.

[joshuap]

I'm not sure about this one. @sorentwo @rabidpraxis does this look familiar?

[sorentwo]

@joshuap This is extremely common. Erlang errors are wrapped by Elixir and will all look like the same error. Some other fingerprinting is necessary to properly differentiate between them.

Having the Postgrex errors wrapped in an ErlangError is strange, though. That may be due to the handle_sasl_reports: true option, as I haven't encountered that particular issue (and dscout has many mis-grouped errors).

[joshuap]

This is extremely common. Erlang errors are wrapped by Elixir and will all look like the same error. Some other fingerprinting is necessary to properly differentiate between them.

Makes sense, thanks! Is the fingerprinting something we could think about handling on our end, or is that unique to each user and better handled via config? (Maybe related: #338)

[sorentwo]

The ErlangError grouping is extremely common and something I'd expect to see handled by the server or library, not something that users should need to do themselves.

[joshuap]

Ok, great. I'll keep this open as an enhancement issue... we'll see if we can find someone to work on that at some point.

[sezaru]

I disabled handle_sasl_reports to see if it improve the situation, now I just need to wait for some errors to pop-up and I will update here my findings.

[sezaru]

At first glance it seems to be working fine now with sasl turned off:

Now maybe the question is why it encapsulates the error into an ErlangError if sasl is on.

[rktjmp]

I am having the same (similar?) error

iex(__@__)4> Honeybadger.notify(%{class: "CustomClass", message: "a matching message"})
:ok

Unless I misunderstand the documentation this is the expected result.

The pattern match here:

https://github.com/honeybadger-io/honeybadger-elixir/blob/c876c08c3d32675031c961183740e5146380b969/lib/honeybadger/notice.ex#L54

doesn't actually pull out class because the struct is an ErlangError, from Exception.Blame.

It's probably fair to assume no elixir exception will ever match %{class: .., message: ...}, so you could probably match on that.

See #359