-
-
Notifications
You must be signed in to change notification settings - Fork 494
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Register Sentry's ErrorSubscriber for Rails 7.0+ apps (#1705)
* Register Sentry's ErrorSubscriber for Rails 7.0+ apps * Mark captured exceptions to avoid duplicated reporting * Prevent ActiveSupport::ExecutionContext pollute reported events in tests * Update changelog
- Loading branch information
Showing
6 changed files
with
66 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
module Sentry | ||
module Rails | ||
# This is not a user-facing class. You should use it with Rails 7.0's error reporter feature and its interfaces. | ||
# See https://github.com/rails/rails/blob/main/activesupport/lib/active_support/error_reporter.rb for more information. | ||
class ErrorSubscriber | ||
def report(error, handled:, severity:, context:) | ||
# a component may already have an integration to capture exceptions while its operation is also wrapped inside an `app.executor.wrap` (e.g. ActionCable) | ||
# in such condition, the exception would be captured repeatedly. it usually happens in this order: | ||
# | ||
# 1. exception captured and reported by the component integration and re-raised | ||
# 2. exception captured by the executor, which then reports it with executor.error_reporter | ||
# | ||
# and because there's no direct communication between the 2 callbacks, we need a way to identify if an exception has been captured before | ||
# using a Sentry-specific intance variable should be the last impactful way | ||
return if error.instance_variable_get(:@__sentry_captured) | ||
Sentry::Rails.capture_exception(error, level: severity, contexts: { "rails.error" => context }, tags: { handled: handled }) | ||
end | ||
end | ||
end | ||
end |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters