Group LiveView exceptions by module

[odarriba]

Hello,

I'm currently testing Phoenix LiveView as a solution for an application that will run on production environments, and I would like to have some security regarding the error reporting using Honeybadger.

Almost everything is great: stacktrace of the error, breadcrumbs, process state reporting, etc.

But I miss some feature that Honeybadger has when controlling exceptions via Plug, and is grouping the exceptions based on the controller (on this case, i suppose it should be by the LiveView module).

I understand it is pretty difficult to guess it by the Logger module, but can it be specified somehow on the context to be recognised by Honeybadger?

Thanks in advance!

[joshuap]

@odarriba I think what you want is to be able to override the "component" (also sometimes called "controller") via Honeybadger.notify/2 and/or Honeybadger.context/1. I'm looking and there is not a way to do this via context, but I think this would work:

Honeybadger.notify(exception, %{component: "custom"})

Is that an option, or do you need to be able to set a custom component for the automatic logging integration?

[odarriba]

What we want to do is to be able to recognise which module has generated the issue. In the case of controllers it can be easily fetch from plug, But i don´t really know if there is a way to implement that in LiveView, as the socket process runs independently to Plug or conn.

My idea was having the ability to set a key in the Honeybadge context to be able to change that groupin" made on the UI based (as far as know) on the controller that takes care of the call when you monitor an HTTP request.

I know that it is not possible to know which LiveView module is an exception from, so maybe that could be configured manually on mount or similar.

[TraceyOnim]

What we want to do is to be able to recognise which module has generated the issue. In the case of controllers it can be easily fetch from plug, But i don´t really know if there is a way to implement that in LiveView, as the socket process runs independently to Plug or conn.

My idea was having the ability to set a key in the Honeybadge context to be able to change that groupin" made on the UI based (as far as know) on the controller that takes care of the call when you monitor an HTTP request.

I know that it is not possible to know which LiveView module is an exception from, so maybe that could be configured manually on mount or similar.

@sorentwo and @joshuap , I can see that HB shows the liveview module an exception is from or am I missing the main point from this issue? is there any follow up done on this?

[sorentwo]

Would a fingerprint override work for this?

[joshuap]

Would a fingerprint override work for this?

Perhaps? 🤔 If someone wants to customize grouping using data in the context, they could create a custom fingerprint adapter:

https://github.com/honeybadger-io/honeybadger-elixir#customizing-error-grouping

What we want to do is to be able to recognise which module has generated the issue. In the case of controllers it can be easily fetch from plug, But i don´t really know if there is a way to implement that in LiveView, as the socket process runs independently to Plug or conn.
My idea was having the ability to set a key in the Honeybadge context to be able to change that groupin" made on the UI based (as far as know) on the controller that takes care of the call when you monitor an HTTP request.
I know that it is not possible to know which LiveView module is an exception from, so maybe that could be configured manually on mount or similar.

@sorentwo and @joshuap , I can see that HB shows the liveview module an exception is from or am I missing the main point from this issue? is there any follow up done on this?

I'm not sure tbh. The new custom fingerprint support should allow people a lot of flexibility for grouping, so I think if there is a question here, it's about what we should be doing by default. In the case of LiveView, we should probably be sending the module in the notice.request.component property. Is that what you're seeing @TraceyOnim?