-
-
Notifications
You must be signed in to change notification settings - Fork 485
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Register Sentry's ErrorSubscriber for Rails 7.0+ apps #1705
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1705 +/- ##
==========================================
- Coverage 98.59% 98.41% -0.18%
==========================================
Files 136 136
Lines 7808 7830 +22
==========================================
+ Hits 7698 7706 +8
- Misses 110 124 +14
Continue to review full report at Codecov.
|
f136ad6
to
c9d107a
Compare
@georgeclaghorn I'd like to hear your opinion on the gotcha and the workaround I took 🙂 |
I don't feel familiar enough with this gem to give a thorough review but this all seems reasonable to me. 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool that we support this now!
c9d107a
to
63225be
Compare
* master: feat(performance): Sync activerecord and net-http span names (getsentry#1681) Register Sentry's ErrorSubscriber for Rails 7.0+ apps (getsentry#1705) Support serializing ActiveRecord job arguments in global id form (getsentry#1688) release: 5.0.2 Fix report_after_job_retries's decision logic (getsentry#1704) Followup of getsentry#1701 (getsentry#1703) Capture transaction tags (getsentry#1701)
Could you expand on that? I'm not sure I follow. |
Interesting. I think this means I can turn on |
This implements the integration proposed in #1630.
After Rails 7.0, you'll be able to use the standardized
Rails.error.record
orRails.error.handle
interfaces to report exceptions to Sentry. Please check ActiveSupport::ErrorReporter for more information.Gotcha & Workaround
If an operation is wrapped inside
app.executor.wrap
, any exception raised will be captured by Rails' error reporter,even if it has been reported by either the SDK integration or user. So in some cases (e.g.
ActionCable
's channel actions), the same error could be reported twice.I worked around this by marking if an exception has been captured by the SDK. And if it has, we don't capture it with the
ErrorSubscriber
.(Dropping the original integration isn't an option because the contextual data may not be accessible from the error reporter)
Closes #1630