Originally created by @NeilBetham on GitHub (Feb 24, 2017).
Would it be possible to use ActiveJob's peform_now instead of perform? The main reason I ask is that using peform_now will call all of the ActiveJob callbacks and error handlers. The error handler callback is particularly important for reporting problems to a error reporting system like Sentry. Is there a reason perform was used instead of perform_now?
Originally created by @NeilBetham on GitHub (Feb 24, 2017).
Would it be possible to use ActiveJob's `peform_now` instead of `perform`? The main reason I ask is that using `peform_now` will call all of the ActiveJob callbacks and error handlers. The error handler callback is particularly important for reporting problems to a error reporting system like Sentry. Is there a reason `perform` was used instead of `perform_now`?
Yes please. I spent 2 hours trying to find why job failures doesn't trigger airbrake notifications until I found that the rescue_from of the ActiveJob is not triggered because Job.new.perform is used instead of perform_now.
@MohamedBassem commented on GitHub (May 2, 2017):
Yes please. I spent 2 hours trying to find why job failures doesn't trigger airbrake notifications until I found that the `rescue_from` of the ActiveJob is not triggered because `Job.new.perform` is used instead of `perform_now`.
so you would need to monkey patch the handle_job_fail method to get this to work.
@edwardmp commented on GitHub (Aug 8, 2017):
As a workaround you can do something like this:
```
class NewRegistrationProcessor
def perform
NewRegistrationProcessorJob.perform_now
end
end
Crono.perform(NewRegistrationProcessor).every 1.minute
```
But I agree it would be better if perform_now is called by default
Edit: in my case, this still doesn't report the error to Rollbar. It seems Crono catches the error elsewhere: https://github.com/plashchynski/crono/blob/5b72e08222047ee6454fd3110904336386e995b9/lib/crono/job.rb#L81
so you would need to monkey patch the `handle_job_fail` method to get this to work.
I have the exact same use-case, reporting errors to Sentry. I came up with another work around that doesn't need monkey patching Crono. Assuming your jobs are subclass of ApplicationJob, define your perform inside ApplicationJob and change the perform method name to something else (in my case perform!) in your job class. Not sure how graceful this work around is, as it requires to change all of your job classes.
class ApplicationJob < ActiveJob::Base
def perform
perform!
rescue StandardError => e
Raven.capture_exception(e)
end
end
class MyFrequntTask < ApplicationJob
def perform!
...
end
end
@sina-s commented on GitHub (Sep 8, 2018):
I have the exact same use-case, reporting errors to Sentry. I came up with another work around that doesn't need monkey patching Crono. Assuming your jobs are subclass of `ApplicationJob`, define your `perform` inside `ApplicationJob` and change the `perform` method name to something else (in my case `perform!`) in your job class. Not sure how graceful this work around is, as it requires to change all of your job classes.
```
class ApplicationJob < ActiveJob::Base
def perform
perform!
rescue StandardError => e
Raven.capture_exception(e)
end
end
```
```
class MyFrequntTask < ApplicationJob
def perform!
...
end
end
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @NeilBetham on GitHub (Feb 24, 2017).
Would it be possible to use ActiveJob's
peform_nowinstead ofperform? The main reason I ask is that usingpeform_nowwill call all of the ActiveJob callbacks and error handlers. The error handler callback is particularly important for reporting problems to a error reporting system like Sentry. Is there a reasonperformwas used instead ofperform_now?@MohamedBassem commented on GitHub (May 2, 2017):
Yes please. I spent 2 hours trying to find why job failures doesn't trigger airbrake notifications until I found that the
rescue_fromof the ActiveJob is not triggered becauseJob.new.performis used instead ofperform_now.@edwardmp commented on GitHub (Aug 8, 2017):
I agree. Is there any reason perform is used because of perform_now?
@edwardmp commented on GitHub (Aug 8, 2017):
As a workaround you can do something like this:
But I agree it would be better if perform_now is called by default
Edit: in my case, this still doesn't report the error to Rollbar. It seems Crono catches the error elsewhere: https://github.com/plashchynski/crono/blob/5b72e08222047ee6454fd3110904336386e995b9/lib/crono/job.rb#L81
so you would need to monkey patch the
handle_job_failmethod to get this to work.@sina-s commented on GitHub (Sep 8, 2018):
I have the exact same use-case, reporting errors to Sentry. I came up with another work around that doesn't need monkey patching Crono. Assuming your jobs are subclass of
ApplicationJob, define yourperforminsideApplicationJoband change theperformmethod name to something else (in my caseperform!) in your job class. Not sure how graceful this work around is, as it requires to change all of your job classes.