Correct retry_intervals exponential backoff documentation (#1014)

The exponential_backoff? docstring claimed retries stop ("before giving
up") after the last configured interval. They do not: once the intervals
are exhausted, get_interval keeps returning the last interval, so the
message is retried indefinitely at that cadence. SQS's redrive policy
(maxReceiveCount) is what actually moves an exhausted message to a
dead-letter queue.

Corrected the docstring to describe the real behavior and added a spec
pinning that far-later attempts keep reusing the last interval, so the
docs and behavior stay in sync.

Signed-off-by: Maciej Mensfeld <maciej@mensfeld.pl>

Author: mensfeld

CHANGELOG.md

@@ -1,11 +1,18 @@
 ## [Unreleased]
 
+- Docs: Correct the `retry_intervals` exponential backoff documentation (mensfeld)
+  - The `exponential_backoff?` docstring claimed retries stop ("before giving up") after the last configured
+    interval. They do not: once the intervals are exhausted, the last interval is reused for every later
+    attempt, and SQS's redrive policy (maxReceiveCount) is what ultimately moves a message to a dead-letter queue
+  - Added a spec pinning that far-later attempts keep reusing the last interval
+
 - Fix: `CurrentAttributes.persist` no longer drops a class when called once per class (mensfeld)
   - The storage key was derived from the per-call index, so registering classes across separate `persist`
     calls made the third call reuse `cattr_0` and silently overwrite the second class - its attributes were
     then never serialized or restored
   - The key now uses the running registry size, so incremental and single-call registration both yield
     distinct, stable keys (single-call `persist(A, B, C)` keys are unchanged)
+
 - Fix: Busy-processor accounting no longer breaks when processor completion raises (mensfeld)
   - `Manager#assign` chained `.then { processor_done }.rescue { processor_done }`, so an exception inside
     `processor_done` (SQS lookups or a polling strategy's `message_processed` callback) ran completion twice

lib/shoryuken/worker.rb

@@ -224,7 +224,11 @@ def auto_visibility_timeout?
       #
       # @example Configuring exponential backoff
       #   shoryuken_options retry_intervals: [1, 5, 25, 125, 625]
-      #   # Will retry after 1s, 5s, 25s, 125s, then 625s before giving up
+      #   # Retries after 1s, 5s, 25s, 125s, then 625s for every later attempt.
+      #   # Shoryuken does not stop retrying on its own once the intervals are
+      #   # exhausted - it keeps reusing the last interval. Configure an SQS
+      #   # redrive policy (maxReceiveCount) to send exhausted messages to a
+      #   # dead-letter queue.
       #
       # @see #shoryuken_options Documentation for configuring retry_intervals
       def exponential_backoff?

spec/lib/shoryuken/middleware/server/exponential_backoff_retry_spec.rb

@@ -92,6 +92,16 @@
 
         expect { subject.call(TestWorker.new, queue, sqs_msg, sqs_msg.body) { raise 'failed' } }.not_to raise_error
       end
+
+      it 'keeps reusing the last interval for far-later attempts (does not give up)' do
+        TestWorker.get_shoryuken_options['retry_intervals'] = [300, 1800]
+
+        allow(sqs_msg).to receive(:attributes) { { 'ApproximateReceiveCount' => 10 } }
+        allow(sqs_msg).to receive(:queue) { sqs_queue }
+        expect(sqs_msg).to receive(:change_visibility).with(visibility_timeout: 1800)
+
+        expect { subject.call(TestWorker.new, queue, sqs_msg, sqs_msg.body) { raise 'failed' } }.not_to raise_error
+      end
     end
 
     context 'and the exception is non-retryable' do