Allow setting component and action through the context

[gstokkink]

Before Rails 8 was released we used the following to explicitly set the component and action when calling Rails.report (to which, so far, only Honeybadger is subscribed):

exception = ...
component = ...
action = ...
context = ...

payload = { exception:, component:, action: }

Rails.error.report(payload, context: ..., ...)

This worked perfectly, the component and action were being correctly rendered by the Honeybadger UI. This was especially useful for explicitly setting the component and action for our jobs (we cannot use the Sidekiq plugin for Honeybadger as we handle errors in a different way). Downside of course is that other error reporters, if we were going to use them, would probably choke on the payload not being an exception.

However, once Rails 8 was released this workaround stopped working. Reason being the addition of this line to ActiveSupport::ErrorReporter:

https://github.com/rails/rails/blob/v8.0.1/activesupport/lib/active_support/error_reporter.rb#L212

This line breaks when the first argument passed in to Rails.error.report does not respond to the backtrace method. There are hacky solutions for this, but maybe it's better if it's possible to pass in the component and action through the context instead, and Honeybadger can retrieve it from the context? That would also be more compatible in the situation of other error reporters than Honeybadger subscribing.

So something like:

exception = ...
component = ...
action = ...
context = ...

Rails.error.report(exception, context: context.merge(component:, action:), ...)

What do you think?

[stympy]

I think this is reasonable, and I threw together a possible implementation in #672.

@joshuap what do you think?

[joshuap]

I think this is reasonable, and I threw together a possible implementation in #672.

@joshuap what do you think?

I think we should think about/discuss a bit more as this as a team. My main concern is that component and action are generic terms, and since context is user/domain-specific data, these terms could conflict with people's existing and future context data—in which case, it would change the grouping of those errors since we include the component in our fingerprint (as well as displaying them in the UI). We do currently have several "magic context keys" such as user_id and user_email, but I think this is a bit different since component and action are really internal Honeybadger properties.

Looping in @subzero10 @rabidpraxis — what do you think?

[gstokkink]

@joshuap agreed with your concerns regarding namespacing. Perhaps adding a honeybadger namespace within the context hash is a good idea?