class Sidekiq::JobRetry

Automatically retry jobs that fail in Sidekiq. Sidekiq’s retry support assumes a typical development lifecycle:

0. Push some code changes with a bug in it.
1. Bug causes job processing to fail, Sidekiq's middleware captures
   the job and pushes it onto a retry queue.
2. Sidekiq retries jobs in the retry queue multiple times with
   an exponential delay, the job continues to fail.
3. After a few days, a developer deploys a fix. The job is
   reprocessed successfully.
4. Once retries are exhausted, Sidekiq will give up and move the
   job to the Dead Job Queue (aka morgue) where it must be dealt with
   manually in the Web UI.
5. After 6 months on the DJQ, Sidekiq will discard the job.

A job looks like:

{ 'class' => 'HardJob', 'args' => [1, 2, 'foo'], 'retry' => true }

The ‘retry’ option also accepts a number (in place of ‘true’):

{ 'class' => 'HardJob', 'args' => [1, 2, 'foo'], 'retry' => 5 }

The job will be retried this number of times before giving up. (If simply ‘true’, Sidekiq retries 25 times)

Relevant options for job retries:

* 'queue' - the queue for the initial job
* 'retry_queue' - if job retries should be pushed to a different (e.g. lower priority) queue
* 'retry_count' - number of times we've retried so far.
* 'error_message' - the message from the exception
* 'error_class' - the exception class
* 'failed_at' - the first time it failed
* 'retried_at' - the last time it was retried
* 'backtrace' - the number of lines of error backtrace to store

We don’t store the backtrace by default as that can add a lot of overhead to the job and everyone is using an error service, right?

The default number of retries is 25 which works out to about 3 weeks You can change the default maximum number of retries in your initializer:

Sidekiq.default_configuration[:max_retries] = 7

or limit the number of retries for a particular job and send retries to a low priority queue with:

class MyJob
  include Sidekiq::Job
  sidekiq_options retry: 10, retry_queue: 'low'
end