Mike Perham c650e9b150 Explicitly signal that we handled an exception with a retry, fixes #4138 (#4141) ... Under just the right conditions, we could lose a job: - Job raises an error - Retry subsystem catches error and tries to create a retry in Redis but this raises a "Redis down" exception - Processor catches Redis exception and thinks a retry was created - Redis comes back online just in time for the job to be acknowledged and lost That's a very specific and rare set of steps but it can happen. Instead have the Retry subsystem raise a specific error signaling that it created a retry. There will be three common cases: 1. Job is successful: job is acknowledged. 2. Job fails, retry is created, Processor rescues specific error: job is acknowledged. 3. Sidekiq::Shutdown is raised: job is not acknowledged Now there is another case: 4. Job fails, retry fails, Processor rescues Exception: job is NOT acknowledged. Sidekiq Pro's super_fetch will rescue the orphaned job at some point in the future.		2019-04-11 18:33:59 -07:00
..
generators/sidekiq	Fix RSpec generated worker template indentation	2017-05-29 10:46:12 -07:00
sidekiq	Explicitly signal that we handled an exception with a retry, fixes #4138 (#4141)	2019-04-11 18:33:59 -07:00
sidekiq.rb	modern terminology	2019-01-07 16:30:27 -08:00