Conversation
since the sdk registers its around_perform as the "first" callback, it needs to call all error handlers manually (which naturally should happen later) to see if it should report the exception. usually, this approach works well because if an exception will be handled later, handling it ealier doesn't make much of a difference. however, as described in #956, if there's another exception happened inside one of the error handlers, it'll re-enter the error handler again in here: https://github.com/rails/rails/blob/38cb5610b1/activejob/lib/active_job/execution.rb#l50-l51 Of course, it may be possible to handle such case by adding more rescue block inside the `capture_and_reraise_with_sentry` method. But it'll force the entire exception handling flow to be performed inside the first `around_perform` block. And that's something we should avoid.
Codecov Report
@@ Coverage Diff @@
## master #1631 +/- ##
==========================================
+ Coverage 98.52% 98.54% +0.01%
==========================================
Files 133 133
Lines 7404 7414 +10
==========================================
+ Hits 7295 7306 +11
+ Misses 109 108 -1
Continue to review full report at Codecov.
|
st0012
added a commit
that referenced
this pull request
Jan 4, 2022
…ion (#1631) * use prepended method instead of around_perform for activejob integration since the sdk registers its around_perform as the "first" callback, it needs to call all error handlers manually (which naturally should happen later) to see if it should report the exception. usually, this approach works well because if an exception will be handled later, handling it ealier doesn't make much of a difference. however, as described in #956, if there's another exception happened inside one of the error handlers, it'll re-enter the error handler again in here: https://github.com/rails/rails/blob/38cb5610b1/activejob/lib/active_job/execution.rb#l50-l51 Of course, it may be possible to handle such case by adding more rescue block inside the `capture_and_reraise_with_sentry` method. But it'll force the entire exception handling flow to be performed inside the first `around_perform` block. And that's something we should avoid. * Refactor ActiveJob integration * Fix SendEventJob's rescue_from callback * Update changelog
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since the sdk registers its around_perform as the "first" callback, it needs to call all error handlers manually (which naturally should happen later) to see if it should report the exception.
Usually, this approach works well because if an exception will be handled later, handling it ealier doesn't make much of a difference.
However, as described in #956, if there's another exception happened inside one of the error handlers, it'll re-enter the error handler again in here: https://github.com/rails/rails/blob/38cb5610b1/activejob/lib/active_job/execution.rb#l50-l51
Of course, it may be possible to handle such case by adding more rescue block inside the
capture_and_reraise_with_sentrymethod. But it'll force the entire exception handling flow to be performed inside the firstaround_performblock. And that's something we should avoid.This also fixes a
rescue_fromcallback issue inSentry::SendEventJob.Closes #956 and #1629