feat: add Rails.event subscriber

[stympy]

Send events recorded by calling Rails.event.notify to Insights.

See rails/rails#55334 for more info

[Copilot]

Pull Request Overview

This PR adds support for subscribing to Rails.event notifications to send structured events to Honeybadger Insights. It introduces a new Rails event subscriber that captures events emitted via Rails.event.notify and forwards them to Honeybadger's event system.

• Implements a new RailsEventSubscriber class to handle Rails.event notifications
• Integrates the subscriber into the Rails plugin with conditional loading for Rails 8.1+ compatibility
• Adds comprehensive test coverage for both available and unavailable Rails.event scenarios

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
lib/honeybadger/plugins/rails.rb	Adds conditional subscription to Rails.event when available
lib/honeybadger/notification_subscriber.rb	Implements RailsEventSubscriber class to process Rails events
spec/integration/rails/event_subscriber_spec.rb	Adds test coverage for Rails event subscription functionality
gemfiles/rails.gemfile	Simplifies Rails gem dependencies to use main branch

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[joshuap]

Love this Rails feature

[rabidpraxis]

Yeah, this is very cool.

[stympy]

I'm having second thoughts about the check for Honeybadger.config.load_plugin_insights_events?(:rails) ... Perhaps that check shouldn't be there, as the intent of that configuration option is to suppress/enable automatic instrumentation of Rails events (e.g., SQL queries reported via ActiveSupport::Notifications), whereas Rails.event is designed to be used intentionally by a developer to log specific events. Thoughts?

[rabidpraxis]

That config name is not screaming it, but I think that makes sense if we want to keep that just for "framework" events.

It seems like we should provide a way to disable this though.

[joshuap]

I'm having second thoughts about the check for Honeybadger.config.load_plugin_insights_events?(:rails) ... Perhaps that check shouldn't be there, as the intent of that configuration option is to suppress/enable automatic instrumentation of Rails events (e.g., SQL queries reported via ActiveSupport::Notifications), whereas Rails.event is designed to be used intentionally by a developer to log specific events. Thoughts?

Agreed, I was thinking this too. I could see cases where people might want to disable the automatic instrumentation, but still get Rails.event in Honeybadger. I think it's similar to calling Honeybadger.event, actually. Also agree w/ Kevin about a way to disable the event integration. I would say rails.insights.events, but that config option already exists for the automatic events. 😅

[stympy]

@joshuap and @rabidpraxis what do you think about the new rails.insights.custom_events option in 7857ff0?

[rabidpraxis]

I like it, but I am wondering if rails.insights.rails_events would be a more descriptive name for the flag.

[joshuap]

I like the idea, but I agree that the insights config is getting pretty confusing with all the similarly named options. With this addition, these are the current insights options that would be relevant for Rails, right?

{
      "insights.enabled": {
        description: "Enable/Disable Honeybadger Insights built-in instrumentation.",
        default: true,
        type: Boolean
      },
      "rails.insights.enabled": {
        description: "Enable automatic data collection for Ruby on Rails.",
        default: true,
        type: Boolean
      },
      "rails.insights.events": {
        description: "Enable automatic event capturing for Ruby on Rails.",
        default: true,
        type: Boolean
      },
      "rails.insights.metrics": {
        description: "Enable automatic metric data collection for Ruby on Rails.",
        default: false,
        type: Boolean
      },
      "rails.insights.custom_events": {
        description: "Enable capturing of custom Rails.event events in Rails 8.1 and later.",
        default: true,
        type: Boolean
      }
}

rails.insights.enabled is a local plugin override for the global insights.enabled option, so that makes sense to me. With the addition of a second events-related option, I kind of wish they were both more specific. Consider this example:

---
rails:
  insights:
    events: false

If you are new to Honeybadger, would you expect that option to disable Rails.event, our custom instrumentation events, or both?

[subzero10]

Apologies for the late reply. I’ve been thinking about this for a few days, but haven’t landed on something I’m fully happy with yet.

I can see how events vs custom_events can cause confusion, especially as we add more instrumentation points.

Here’s what I currently have in mind:

• insights.enabled → Global kill switch for all Honeybadger Insights instrumentation.
• rails.insights.enabled → Rails-specific kill switch for Honeybadger Insights.
• rails.insights.active_support_events → Enable/disable ActiveSupport notifications instrumentation.
• rails.insights.structured_events → Enable/disable Rails structured log instrumentation.

This raises a few questions for me:

1. If we rename the generic events key, what happens to other plugin options like puma.insights.events? Would those need to change for consistency? (my guess is that we won't change those)
2. If we go with a more specific name, is instrumented_events specific enough (I know Ben mentioned this one)? Why not just use something explicit like rails.insights.active_support_events, since that’s what this plugin currently hooks into?
3. Do we anticipate adding non–ActiveSupport event listeners in the Rails plugin in the future? If not, I’d lean toward the explicit name.
4. For the new Rails 8.1 feature, I’d prefer calling it structured_events to avoid duplication in the full key (rails.insights.structured_events feels cleaner than rails.insights.rails_events), and it matches how the feature was announced in the Rails 8.1 release notes.

[Copilot]

Pull Request Overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The first argument to Honeybadger.event should be the event type, but event[:name] is being passed. Based on the test expectations (line 18 of the spec expects event_type to equal \"test.rails_event\"), this should use the event name/type from the Rails.event notification. However, Rails.event likely doesn't include a :name key in its payload - it would be the first argument to Rails.event.notify(). Review the Rails.event API to determine the correct key to extract the event type from the event hash.

Suggested change

	Honeybadger.event(event[:name], event.except(:name, :timestamp))
	Honeybadger.event(event.name, event.payload)

[joshuap]

@stympy is there anything left to do on this PR?