Rails ActiveJob has a retry_on hook that allows you to customize retry behavior. For example:
retry_on AnotherCustomAppException, wait: ->(executions) { executions * 2 }
Rails also passes the current retry number as executions
with the job_data
and there's a retry_job
method for further customization.
However, if you use the delayed_job_active_record gem as your backend, it looks like there's a separate config called max_attempts that controls the retry behavior.
My question is, if you use the delayed_job_active_record backend, can you still use retry_on
without issues?
If you can't use retry_on
, then what would be an appropriate strategy for imitating that customization of rescues?
When you're using delayed_job
as a backend to ActiveJob
, you end up with two retry mechanisms: first from ActiveJob
, configurable using the retry_on
method, and second from delayed_job
, which is controlled by the max_attempts
variable.
You can turn off the retry behaviour from delayed_job with the following:
# in config/initializers/delayed_job.rb
Delayed::Worker.max_attempts = 1
Now your retries are controlled entirely by the ActiveJob retry_on
call, which should result in predictable behaviour.