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

@joshuap what do you think?

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?

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

I don’t have a strong opinion on this (and that’s probably why it took me a few days to reply 😅), but one way to approach this would be to first define what the ideal solution would look like without the constraints of the current implementation. Then, once we’ve settled on that, we can figure out how to bridge the gap between the current behavior and the ideal solution.

If we look at component and action purely from a design perspective:

• They describe the context where the error happened, so it makes sense to treat them as contextual metadata rather than core error properties.
• Since component and action aren’t inherent attributes of the exception itself (like message or backtrace), it feels natural to nest them within the context hash rather than passing them alongside the exception.

With that in mind, I think a safe approach could be:

1. Prefix component and action inside the context hash (e.g., honeybadger_component, honeybadger_action) to avoid namespace collisions, as @gstokkink suggested.
2. Extract those keys internally before sending the payload to Honeybadger, setting them on the top-level component and action fields as we do today.

This approach would:

• Ensure compatibility with Rails 8 by sticking to the intended Rails.error.report API.
• Avoid breaking users who might already be passing component or action in their own context data.
• Maintain backwards compatibility without requiring users to update their existing error reporting code.

@subzero10 completely agree. Perhaps using context: { honeybadger: { component:, action: }, ... } is more future-proof than context: { honeybadger_component:, honeybadger_action:, ... } when it comes to adding additional Honeybadger-specific contextual settings.

• They describe the context where the error happened, so it makes sense to treat them as contextual metadata rather than core error properties.

• Since component and action aren’t inherent attributes of the exception itself (like message or backtrace), it feels natural to nest them within the context hash rather than passing them alongside the exception.

If component and action really are context, I suppose we could make them official special keys, similar to user_id and user_email, and list them in our docs:

https://docs.honeybadger.io/guides/errors/#context-data

I just remembered that we also do something similar for tags in Ruby, so maybe we've already crossed this Rubicon?

https://docs.honeybadger.io/lib/ruby/getting-started/adding-context-to-errors/#special-context-values

Just trying to think through all the implications of this. I think I'm warming to the idea of keeping them more general top-level keys (component and action) and adding it to the docs. 😅

Just trying to think through all the implications of this. I think I'm warming to the idea of keeping them more general top-level keys (component and action) and adding it to the docs. 😅

To clarify, with this you are saying that we could add the to the context hash without namespacing them, right?
Considering that we already have support for special keys, this just means we are adding to that list, so yeah it makes sense to me.

Another benefit with this solution would be that we can implement this change in the Honeybadger backend instead of having to add code in the client libraries to extract component and action keys from context before sending them to Honeybadger (the second point of my suggested approach above).

Finally, if I understand correctly, the only concern with this solution is that it could create confusion for customers already using context.component and context.action with different values than the top-level component and action values. This seems unlikely to me, but I wonder if there's an easy way to verify this (i.e. query a sample of fairly recent errors)?

Today I was working on a wordpress-plugin for Honeybadger and I just came across this in our PHP library. It seems that for the PHP library, we support setting component and action through context, prefixed with honeybadger_, and extracting them just before sending the report to Honeybadger:

'request' => [
  // ....
  'context' => $this->context->except(['honeybadger_component', 'honeybadger_action']) ?: new stdClass,
  'component' => Arr::get($this->additionalParams, 'component', null) ?? Arr::get($this->context, 'honeybadger_component', null),
  'action' => Arr::get($this->additionalParams, 'action', null) ?? Arr::get($this->context, 'honeybadger_action', null),
],