feat: derive _component from stacktrace for better error grouping

[stympy]

Problem

Jim reported (in #668) that different Ecto.ConstraintError exceptions from different locations in their application were being grouped together as the same error in Honeybadger. This caused issues with integrations (like Shortcut) where resolved issues would unexpectedly reopen.

Root Cause

Honeybadger's fingerprinting algorithm uses three fields to group errors:

• Exception class (e.g., "Ecto.ConstraintError")
• Component (e.g., controller name)
• First application backtrace frame (file:method:line)

For non-web errors (background jobs, GenServers, Tasks), there's no Phoenix controller, so component is empty. When two different constraint errors both flow through the same Ecto.Repo module, they can end up with identical fingerprints:

hexdigest("Ecto.ConstraintError", "", "lib/my_app/repo.ex:insert:100")

Even though they originate from completely different parts of the application (e.g., MyApp.Users vs MyApp.Orders).

Solution

This PR automatically derives _component from the stacktrace for non-web errors. The ComponentDeriver module:

1. Walks through stack frames looking for modules belonging to the configured :app
2. Skips "infrastructure" modules (Ecto.Repo, Ecto.Changeset, Postgrex, DBConnection, etc.) that don't indicate the error's true origin
3. Sets the first suitable module as _component in the context

The Honeybadger API parser already looks for _component in the context (before falling back to request.component), so this provides differentiated fingerprints:

hexdigest("Ecto.ConstraintError", "MyApp.Users", "lib/my_app/repo.ex:insert:100")
hexdigest("Ecto.ConstraintError", "MyApp.Orders", "lib/my_app/repo.ex:insert:100")

Configuration

Users can customize which modules are skipped:

config :honeybadger,
  component_deriver_skip_patterns: [
    MyApp.CustomInfraModule,      # atom
    ~r/^MyApp\.Internal/,         # regex
    "MyApp.Utilities"             # string
  ]

Workaround (for users on older versions)

Users who can't upgrade immediately can work around this by explicitly setting context before operations that might fail:

Honeybadger.context(_component: "MyApp.Users", _action: "create")

Or by implementing a custom fingerprint adapter:

config :honeybadger, fingerprint_adapter: MyApp.FingerprintAdapter

Test plan

• Added unit tests for ComponentDeriver module (14 tests)
• Added integration tests in NoticeTest (5 tests)
• Verified existing tests still pass
• Tested that component is derived correctly from stacktraces
• Tested that existing plug_env components are not overridden
• Tested that user-set _component in context is respected

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR addresses an error grouping issue where different Ecto.ConstraintError exceptions from different locations were being grouped together in Honeybadger. The solution derives a component name from the stacktrace for non-web errors to provide better fingerprinting differentiation.

Changes:

• Added new ComponentDeriver module to derive component names from stacktraces by identifying the first application module that isn't infrastructure (Ecto, Postgrex, etc.)
• Integrated component derivation into Notice.new/3 with proper precedence (user-set > plug_env > derived)
• Added configuration support for customizing skipped patterns via :component_deriver_skip_patterns

Reviewed changes

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

File	Description
lib/honeybadger/component_deriver.ex	New module that walks stacktraces to find suitable component modules, with configurable skip patterns for infrastructure modules
lib/honeybadger/notice.ex	Updated to derive _component from stacktrace when no component exists from plug_env or user context
test/honeybadger/component_deriver_test.exs	Comprehensive unit tests (14 tests) covering derivation logic, skip patterns, and edge cases
test/honeybadger/notice_test.exs	Integration tests (5 tests) verifying component derivation behavior in notice creation

---

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

[subzero10]

Looks good to me (thank you Claude for all the comments) 😄.

Note: CI is failing because of bad formatting.

[rabidpraxis]

Two things I'm wondering about:

I'm pretty sure that app_matches? will filter out all the included default_skip_patterns, as each one of those module's applications should not match against the app name, which makes the pattern match useless (unless the app name is the same as those core libraries, which should be very rare).

Secondly, I don't think this will fix the original issue out of the box. If we are checking for the first user stacktrace, then it would match MyApp.Repo, which in the example would be the same for all of the Ecto.ConstraintError fingerprints, still grouping them together.

What if we remove the current default skip patterns (as they're redundant with app_matches?), but keep the user-configurable skip patterns mechanism. Then automatically add the modules from the :ecto_repos config to the skip list, as that should skip any Ecto plumbing calls within the app.