Calling the error handler twice when raising an exception in a rescue_from block #956
Comments
donaldong
changed the title
|
thanks for reporting, can you provide a minimum app that can reproduce the issue? thanks |
|
I was able to reproduce it in my environment. see https://github.com/sinshutu/sample-rails-sentry-calling-the-error-handler-twice/tree/main Just run ./setup.sh and you will see it run twice! |
|
@sinshutu thanks for the feedback. I've reopened this issue and will check it later. |
st0012
added a commit
that referenced
this issue
Nov 27, 2021
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.
st0012
added a commit
that referenced
this issue
Dec 1, 2021
…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
st0012
added a commit
that referenced
this issue
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using an ActiveJob Adapter which is not listed in
https://github.com/getsentry/raven-ruby/blob/ff59e93057ac8ac98603f8745f5024df7ed47dc2/lib/raven/integrations/rails/active_job.rb#L4
capture_and_reraise_with_sentry calls
rescue_with_handlerhttps://github.com/getsentry/raven-ruby/blob/ff59e93057ac8ac98603f8745f5024df7ed47dc2/lib/raven/integrations/rails/active_job.rb#L21-L24
However, if the error handler (defined by a rescue_from) raises an error, the same error will be reported to the error handler itself again (double calling the error handler).
Curious what would be a proper workaround? If no workaround seems reasonable, can we provide a way to skip capture_and_reraise_with_sentry (or simply disable the
ActiveJobExtensions)?The text was updated successfully, but these errors were encountered: