-
-
Notifications
You must be signed in to change notification settings - Fork 503
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
add report_after_job_retries support for ActiveJob #2500
base: master
Are you sure you want to change the base?
add report_after_job_retries support for ActiveJob #2500
Conversation
5ecd340
to
2be327a
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2500 +/- ##
==========================================
- Coverage 98.16% 96.99% -1.18%
==========================================
Files 128 126 -2
Lines 4847 4787 -60
==========================================
- Hits 4758 4643 -115
- Misses 89 144 +55
|
79897d2
to
0ce620d
Compare
923d2d3
to
daee3d8
Compare
@solnic could you review and get this merged if you have time? |
@sl0thentr0py looking into it today |
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.
I've been digging into this and I don't think it works as expected and the test results are misleading. The spec actually ends up with 3 errors logged and I do not understand how it happens.
I added this pp
statement to the spec:
context "when active_job_report_after_job_retries is true" do
before do
Sentry.configuration.rails.active_job_report_after_job_retries = true
end
after do
Sentry.configuration.rails.active_job_report_after_job_retries = false
end
it "reports 1 exception" do
assert_performed_jobs 3 do
FailedJobWithRetryOn.perform_later rescue nil
end
pp transport.events.first.exception.values
expect(Sentry::Rails::ActiveJobExtensions::SentryReporter)
.to have_received(:capture_exception)
.exactly(1).times
end
and here's the output:
[#<Sentry::SingleExceptionInterface @type="FailedJob::TestError", @value="Boom! (FailedJob::TestError)", @module="FailedJob", @thread_id=12700, @mechanism=#<Sentry::Mechanism:0x0000ffff6340aa70 @type="rails", @handled=false>>,
#<Sentry::SingleExceptionInterface @type="FailedJob::TestError", @value="Boom! (FailedJob::TestError)", @module="FailedJob", @thread_id=12700, @mechanism=#<Sentry::Mechanism:0x0000ffff6340aa70 @type="rails", @handled=false>>,
#<Sentry::SingleExceptionInterface @type="FailedJob::TestError", @value="Boom! (FailedJob::TestError)", @module="FailedJob", @thread_id=12700, @mechanism=#<Sentry::Mechanism:0x0000ffff6340aa70 @type="rails", @handled=false>>]
Any ideas what is reporting these errors? It happens regardless if we use mocks or not.
Description
this pr adds
report_after_job_retries
support toActiveJob
(configured viaconfig.rails.active_job_report_after_job_retries
).the easiest way to do this would have been to use retry_on in the base
ActiveJob
class (similar to here) but that's difficult to do properly which is (i think) why the currentActiveJob
integration doesn't do it.instead we can take advantage of the
retry_stopped.active_job
notification that's published when a job runs out of retries. this makes our setup a single call toActiveSupport::Notifications.subscribe
.fixes #2499