shoryuken 7.0.2 → 7.0.3

data/spec/integration/auto_extend_visibility/short_visibility_timeout_spec.rb

@@ -0,0 +1,52 @@
+# frozen_string_literal: true
+
+# This spec tests that auto_visibility_timeout still processes messages when the
+# queue's visibility timeout is short (<= EXTEND_UPFRONT_SECONDS).
+#
+# AutoExtendVisibility schedules a TimerTask at execution_interval =
+# visibility_timeout - EXTEND_UPFRONT_SECONDS (5s). When the queue's visibility
+# timeout is <= 5s that interval is <= 0, and TimerTask#initialize raises
+# ArgumentError *before* the worker runs - so every receive fails and the
+# message is reprocessed (and re-fails) until it hits a DLQ.
+#
+# Expected behavior: a short visibility timeout no longer breaks processing; the
+# extension interval is clamped to a positive value and the worker runs normally.
+#
+# Regression: auto_visibility_timeout + a <= 5s queue visibility timeout broke
+# processing entirely.
+
+require 'timeout'
+
+setup_sqs
+
+DT.clear
+
+queue_name = DT.queue
+# 5s visibility timeout -> interval would be 5 - 5 = 0 -> TimerTask raised pre-fix.
+create_test_queue(queue_name, attributes: { 'VisibilityTimeout' => '5' })
+Shoryuken.add_group('default', 1)
+Shoryuken.add_queue(queue_name, 1, 'default')
+
+short_vt_worker = Class.new do
+  include Shoryuken::Worker
+
+  shoryuken_options auto_delete: true, auto_visibility_timeout: true
+
+  def perform(_sqs_msg, body)
+    DT[:processed] << body
+  end
+end
+
+short_vt_worker.get_shoryuken_options['queue'] = queue_name
+Shoryuken.register_worker(queue_name, short_vt_worker)
+
+queue_url = Shoryuken::Client.sqs.get_queue_url(queue_name: queue_name).queue_url
+Shoryuken::Client.sqs.send_message(queue_url: queue_url, message_body: 'hello')
+
+poll_queues_until(timeout: 20) { DT[:processed].size >= 1 }
+
+assert_equal(
+  ['hello'],
+  DT[:processed].to_a,
+  'auto_visibility_timeout must not break processing on a queue with a short visibility timeout'
+)

data/spec/integration/concurrent_processing/processor_accounting_spec.rb

@@ -0,0 +1,94 @@
+# frozen_string_literal: true
+
+# This spec tests that the manager's busy-processor accounting stays correct
+# when processor completion handling itself raises.
+#
+# Manager#processor_done makes SQS calls (Shoryuken::Client.queues, #fifo?)
+# and invokes the polling strategy's message_processed callback (a documented
+# extension point) - any of these can raise, e.g. on a transient network
+# error or a bug in a custom strategy.
+#
+# Expected behavior: processor_done runs exactly once per processed message
+# and busy_processors never goes negative, even when processor_done raises.
+#
+# Regression: Manager#assign chained `.then { processor_done }` with
+# `.rescue { processor_done }`, so an exception inside processor_done
+# rejected the then-promise and ran processor_done a SECOND time. The busy
+# counter was decremented twice for one message and drifted negative,
+# inflating `ready` and silently breaking the concurrency limit for the
+# life of the process.
+
+require 'timeout'
+
+setup_sqs
+
+DT.clear
+
+queue_name = "#{DT.uuid}.fifo"
+create_fifo_queue(queue_name)
+
+# A custom polling strategy whose message_processed callback raises, like a
+# buggy user strategy or one that performs I/O and hits a transient error.
+# Manager#processor_done invokes it for FIFO queues.
+class FlakyCallbackStrategy < Shoryuken::Polling::WeightedRoundRobin
+  def message_processed(queue)
+    DT[:message_processed_calls] << { queue: queue, time: Time.now }
+    raise 'flaky message_processed callback'
+  end
+end
+
+Shoryuken.add_group('default', 2, polling_strategy: FlakyCallbackStrategy)
+Shoryuken.add_queue(queue_name, 1, 'default')
+
+accounting_worker = Class.new do
+  include Shoryuken::Worker
+
+  shoryuken_options auto_delete: true
+
+  def perform(_sqs_msg, body)
+    DT[:processed] << body
+  end
+end
+
+accounting_worker.get_shoryuken_options['queue'] = queue_name
+Shoryuken.register_worker(queue_name, accounting_worker)
+
+# busy_processors is exposed through the public utilization_update event
+Shoryuken.on(:utilization_update) do |opts|
+  DT[:utilization] << opts.dup
+end
+
+launcher = Shoryuken::Launcher.new
+launcher.start
+
+begin
+  Shoryuken::Client.queues(queue_name).send_message(message_body: 'hello')
+
+  # Wait for the message to be processed and the completion path to run
+  Timeout.timeout(15) { sleep 0.5 until DT[:message_processed_calls].size >= 1 }
+
+  # Give the (buggy) rescue path time to run processor_done a second time
+  sleep 3
+
+  assert_equal(['hello'], DT[:processed].to_a, 'Message should have been processed exactly once')
+
+  assert_equal(
+    1,
+    DT[:message_processed_calls].size,
+    'processor_done must run exactly once per message, even when it raises ' \
+    "(message_processed was called #{DT[:message_processed_calls].size} times)"
+  )
+
+  negative = DT[:utilization].select { |u| u[:busy_processors].negative? }
+  assert(
+    negative.empty?,
+    'busy_processors must never go negative; a double decrement inflates ready ' \
+    "and breaks the concurrency limit (saw: #{negative.first.inspect})"
+  )
+ensure
+  begin
+    Timeout.timeout(10) { launcher.stop }
+  rescue Timeout::Error
+    nil
+  end
+end

data/spec/integration/fifo_ordering/fifo_max_messages_cap_spec.rb

@@ -0,0 +1,96 @@
+# frozen_string_literal: true
+
+# A custom polling strategy can put :max_number_of_messages in the
+# QueueConfiguration options. For a FIFO queue that must never raise the
+# per-receive count above 1: SQS can otherwise return several messages from the
+# same group in one receive, which Shoryuken would hand to separate processor
+# threads and run concurrently / out of order.
+#
+# This drives a real launcher with a strategy that asks for 10 messages per
+# receive and asserts, end-to-end, that the fetcher still caps the FIFO request
+# to 1 (and that the messages are processed in order). The assertion on the
+# requested count is deterministic regardless of how the SQS backend chooses to
+# respond.
+
+require 'delegate'
+
+setup_sqs
+
+# Records the max_number_of_messages Shoryuken actually asks SQS for, then
+# forwards every call unchanged to the real client.
+class RecordingSqsClient < SimpleDelegator
+  def receive_message(params)
+    DT[:receive_max] << params[:max_number_of_messages]
+    __getobj__.receive_message(params)
+  end
+end
+
+Shoryuken::Client.sqs = RecordingSqsClient.new(Shoryuken::Client.sqs)
+
+# Strategy that requests 10 messages per receive via the queue options - the
+# value the FIFO guard must clamp back down to 1.
+class MaxOverridePollingStrategy < Shoryuken::Polling::BaseStrategy
+  def initialize(queues, _delay = nil)
+    @queue = queues.first
+    @paused_until = Time.at(0)
+  end
+
+  def next_queue
+    return nil if Time.now < @paused_until
+
+    Shoryuken::Polling::QueueConfiguration.new(@queue, max_number_of_messages: 10)
+  end
+
+  # Pause briefly on an empty poll so the dispatch loop doesn't busy-spin once
+  # the queue is drained.
+  def messages_found(_queue, count)
+    @paused_until = Time.now + 0.5 if count.zero?
+  end
+
+  def active_queues
+    [[@queue, 1]]
+  end
+end
+
+queue_name = "#{DT.uuid}.fifo"
+create_fifo_queue(queue_name)
+Shoryuken.add_group('default', 1, polling_strategy: MaxOverridePollingStrategy)
+Shoryuken.add_queue(queue_name, 1, 'default')
+
+worker_class = Class.new do
+  include Shoryuken::Worker
+
+  def perform(_sqs_msg, body)
+    DT[:processed] << body
+  end
+end
+worker_class.get_shoryuken_options['queue'] = queue_name
+worker_class.get_shoryuken_options['auto_delete'] = true
+worker_class.get_shoryuken_options['batch'] = false
+Shoryuken.register_worker(queue_name, worker_class)
+
+queue_url = Shoryuken::Client.sqs.get_queue_url(queue_name: queue_name).queue_url
+
+3.times do |i|
+  Shoryuken::Client.sqs.send_message(
+    queue_url: queue_url,
+    message_body: "msg-#{i}",
+    message_group_id: 'group-a',
+    message_deduplication_id: SecureRandom.uuid
+  )
+end
+
+sleep 1
+
+poll_queues_until { DT[:processed].size >= 3 }
+
+# Messages were processed, in order...
+assert_equal(%w[msg-0 msg-1 msg-2], DT[:processed])
+
+# ...and every FIFO receive requested at most one message, even though the
+# strategy asked for ten - the one-at-a-time guard stays authoritative.
+assert(DT[:receive_max].any?, 'expected at least one receive_message call')
+assert(
+  DT[:receive_max].all? { |max| max == 1 },
+  "FIFO receive should cap max_number_of_messages at 1, saw: #{DT[:receive_max].uniq.inspect}"
+)

data/spec/integration/launcher/double_graceful_stop_spec.rb

@@ -0,0 +1,71 @@
+# frozen_string_literal: true
+
+# This spec tests that a second graceful stop returns instead of deadlocking.
+#
+# Operationally this is the TSTP -> USR1 sequence: Runner handles TSTP by
+# calling Launcher#stop ("stop accepting new work") and a later USR1 calls
+# Launcher#stop again for the final soft shutdown.
+#
+# Regression: Manager#await_dispatching_in_progress popped a Queue that
+# received exactly one signal when the dispatch loop observed the stop flag.
+# A second Launcher#stop popped an empty queue and blocked forever, leaving
+# the process stuck in the signal loop where even TERM/INT were no longer
+# processed - only SIGKILL could stop it.
+
+require 'timeout'
+
+setup_sqs
+
+DT.clear
+
+queue_name = DT.queue
+create_test_queue(queue_name)
+Shoryuken.add_group('default', 1)
+Shoryuken.add_queue(queue_name, 1, 'default')
+
+stop_worker = Class.new do
+  include Shoryuken::Worker
+
+  shoryuken_options auto_delete: true
+
+  def perform(_sqs_msg, body)
+    DT[:processed] << body
+  end
+end
+
+stop_worker.get_shoryuken_options['queue'] = queue_name
+Shoryuken.register_worker(queue_name, stop_worker)
+
+queue_url = Shoryuken::Client.sqs.get_queue_url(queue_name: queue_name).queue_url
+
+launcher = Shoryuken::Launcher.new
+launcher.start
+
+begin
+  # Prove the launcher is fully up and dispatching before stopping it
+  Shoryuken::Client.sqs.send_message(queue_url: queue_url, message_body: 'before stop')
+  Timeout.timeout(10) { sleep 0.5 until DT[:processed].size >= 1 }
+
+  # First graceful stop (TSTP: "stop accepting new work")
+  Timeout.timeout(10) { launcher.stop }
+
+  # Second graceful stop (USR1 after TSTP: final soft shutdown).
+  # This must return promptly instead of blocking forever.
+  begin
+    Timeout.timeout(10) { launcher.stop }
+  rescue Timeout::Error
+    raise IntegrationsHelper::TestFailure,
+          'Second Launcher#stop deadlocked: await_dispatching_in_progress blocked on an empty signal queue ' \
+          '(TSTP -> USR1 leaves the process unkillable except SIGKILL)'
+  end
+
+  assert_equal(['before stop'], DT[:processed].to_a, 'Message sent before shutdown should have been processed')
+ensure
+  # Best-effort cleanup so a failure above never leaves a live launcher behind.
+  # On the happy path this is also a third stop, exercising idempotent shutdown.
+  begin
+    Timeout.timeout(10) { launcher.stop }
+  rescue Timeout::Error
+    nil
+  end
+end

data/spec/integration/launcher/embedded_dispatch_error_spec.rb

@@ -0,0 +1,85 @@
+# frozen_string_literal: true
+
+# This spec tests that a fatal dispatch error does not hard-kill the host
+# process when Shoryuken runs embedded (Launcher used directly, without the
+# CLI Runner).
+#
+# When the dispatch loop hits an unrecoverable error (e.g. SQS still failing
+# after the fetcher exhausts its retries), Manager#handle_dispatch_error used
+# to send Process.kill('USR1', Process.pid) unconditionally. The CLI Runner
+# traps USR1 and turns it into a graceful shutdown, but an embedded host has
+# USR1's default disposition, which terminates the whole process - killing any
+# in-flight workers.
+#
+# Expected behavior when embedded: the failing manager stops itself and
+# Launcher#healthy? reports the failure; no process-killing signal is sent.
+#
+# Regression: embedded mode received an untrapped USR1 and the process died.
+
+require 'timeout'
+
+setup_sqs
+
+DT.clear
+
+queue_name = DT.queue
+create_test_queue(queue_name)
+Shoryuken.add_group('default', 1)
+Shoryuken.add_queue(queue_name, 1, 'default')
+
+embedded_worker = Class.new do
+  include Shoryuken::Worker
+
+  shoryuken_options auto_delete: true
+
+  def perform(_sqs_msg, _body); end
+end
+
+embedded_worker.get_shoryuken_options['queue'] = queue_name
+Shoryuken.register_worker(queue_name, embedded_worker)
+
+# Force every fetch to fail so the dispatch loop reaches handle_dispatch_error.
+# Prepend (rather than redefine) to avoid method-redefinition warnings.
+failing_fetch = Module.new do
+  def fetch(*)
+    raise 'simulated persistent fetch failure'
+  end
+end
+Shoryuken::Fetcher.prepend(failing_fetch)
+
+# Safely observe whether the process is signalled with USR1. A real embedded
+# host has the default (lethal) disposition; here we trap it only so the test
+# runner survives long enough to assert that the signal is not sent. The trap
+# runs on the main thread, so a plain boolean assignment (no lock, no
+# allocation) is trap-safe and visible to the assertions below.
+usr1_received = false
+previous_handler = Signal.trap('USR1') { usr1_received = true }
+
+launcher = Shoryuken::Launcher.new
+launcher.start
+
+begin
+  # The failing dispatch should drive the manager - and therefore the launcher -
+  # unhealthy.
+  Timeout.timeout(15) { sleep 0.2 while launcher.healthy? }
+
+  # Give any (buggy) USR1 a chance to be delivered and handled.
+  sleep 1
+
+  refute(
+    usr1_received,
+    'Embedded mode must not send USR1 on a fatal dispatch error: with no Runner ' \
+    'trapping it, the default disposition terminates the host process and its ' \
+    'in-flight workers'
+  )
+
+  assert(!launcher.healthy?, 'Launcher should report unhealthy after a fatal dispatch error')
+ensure
+  Signal.trap('USR1', previous_handler || 'DEFAULT')
+
+  begin
+    Timeout.timeout(10) { launcher.stop }
+  rescue Timeout::Error
+    nil
+  end
+end

data/spec/integration/launcher/global_executor_preserved_spec.rb

@@ -0,0 +1,76 @@
+# frozen_string_literal: true
+
+# This spec tests that stopping the launcher does not destroy the process-wide
+# Concurrent.global_io_executor.
+#
+# When no launcher_executor is configured, Launcher#executor used to fall back
+# to Concurrent.global_io_executor - and Launcher#stop / #stop! call
+# executor.shutdown (and kill). That pool is a process-global singleton shared
+# by anything using concurrent-ruby's :io pool (including Shoryuken's own
+# ShoryukenConcurrentSendAdapter), so shutting it down breaks unrelated work and
+# prevents a fresh launcher from being started in the same process.
+#
+# Expected behavior: the launcher owns a dedicated executor, so stopping it
+# leaves the global IO executor untouched.
+#
+# Regression: stopping the launcher shut down/killed the global IO executor.
+
+require 'timeout'
+
+setup_sqs
+
+# Exercise the real default executor path. The integrations helper injects a
+# dedicated pool via launcher_executor; production CLI/embedded use leaves it
+# nil, which is exactly the path that fell back to the global pool.
+Shoryuken.define_singleton_method(:launcher_executor) { nil }
+
+DT.clear
+
+queue_name = DT.queue
+create_test_queue(queue_name)
+Shoryuken.add_group('default', 1)
+Shoryuken.add_queue(queue_name, 1, 'default')
+
+worker = Class.new do
+  include Shoryuken::Worker
+
+  shoryuken_options auto_delete: true
+
+  def perform(_sqs_msg, body)
+    DT[:processed] << body
+  end
+end
+
+worker.get_shoryuken_options['queue'] = queue_name
+Shoryuken.register_worker(queue_name, worker)
+
+queue_url = Shoryuken::Client.sqs.get_queue_url(queue_name: queue_name).queue_url
+
+launcher = Shoryuken::Launcher.new
+launcher.start
+
+Shoryuken::Client.sqs.send_message(queue_url: queue_url, message_body: 'hello')
+Timeout.timeout(15) { sleep 0.2 until DT[:processed].size >= 1 }
+
+launcher.stop!
+
+# The process-global IO executor must still be running after the launcher stops.
+assert(
+  Concurrent.global_io_executor.running?,
+  'Launcher must not shut down the process-global IO executor on stop; ' \
+  'other code (including ShoryukenConcurrentSendAdapter) relies on it'
+)
+
+# ...and it must still actually run work scheduled on it.
+result =
+  begin
+    Concurrent::Promises.future_on(Concurrent.global_io_executor) { 42 }.value(5)
+  rescue Concurrent::RejectedExecutionError
+    nil
+  end
+
+assert_equal(
+  42, result,
+  'A task scheduled on the global IO executor after the launcher stops should still run; ' \
+  'the launcher destroyed the shared pool'
+)

data/spec/integration/launcher/graceful_stop_timeout_spec.rb

@@ -0,0 +1,74 @@
+# frozen_string_literal: true
+
+# This spec tests that a graceful stop is bounded by the configured timeout and
+# does not block forever on a worker that refuses to finish.
+#
+# Launcher#stop (the soft shutdown behind USR1/TSTP) waits for in-flight workers
+# to finish so their messages are not redelivered. It used to call
+# executor.wait_for_termination with no argument - an unbounded wait - so a
+# single hung worker would block the shutdown forever (and, because the signal
+# loop is stuck, leave the process killable only with SIGKILL).
+#
+# Expected behavior: workers get up to Shoryuken.options[:timeout] seconds to
+# finish, after which the executor is killed and stop returns. Launcher#stop!
+# already did this; Launcher#stop should too.
+#
+# Regression: a hung worker hung Launcher#stop indefinitely.
+
+require 'timeout'
+
+setup_sqs
+
+DT.clear
+
+# Short grace period so the test is fast; the worker hangs well past it.
+Shoryuken.options[:timeout] = 2
+
+queue_name = DT.queue
+create_test_queue(queue_name)
+Shoryuken.add_group('default', 1)
+Shoryuken.add_queue(queue_name, 1, 'default')
+
+hanging_worker = Class.new do
+  include Shoryuken::Worker
+
+  shoryuken_options auto_delete: true
+
+  def perform(_sqs_msg, _body)
+    DT[:started] << true
+    # Hang far longer than the grace period to simulate a stuck worker.
+    sleep 60
+  end
+end
+
+hanging_worker.get_shoryuken_options['queue'] = queue_name
+Shoryuken.register_worker(queue_name, hanging_worker)
+
+queue_url = Shoryuken::Client.sqs.get_queue_url(queue_name: queue_name).queue_url
+
+launcher = Shoryuken::Launcher.new
+launcher.start
+
+Shoryuken::Client.sqs.send_message(queue_url: queue_url, message_body: 'hang')
+
+# Make sure the worker is genuinely in-flight before we stop.
+Timeout.timeout(15) { sleep 0.2 until DT[:started].size >= 1 }
+
+# Graceful stop must return within roughly the grace period, not block for the
+# full 60s the worker sleeps. Allow generous margin over the 2s timeout.
+started_at = Time.now
+begin
+  Timeout.timeout(20) { launcher.stop }
+rescue Timeout::Error
+  raise IntegrationsHelper::TestFailure,
+        'Launcher#stop blocked past the configured timeout on a hung worker: ' \
+        'a graceful stop must bound executor.wait_for_termination and kill the ' \
+        'executor when exceeded (an unbounded wait hangs USR1/TSTP shutdown forever)'
+end
+elapsed = Time.now - started_at
+
+assert(
+  elapsed < 15,
+  "Graceful stop should return shortly after the #{Shoryuken.options[:timeout]}s timeout, " \
+  "took #{elapsed.round(1)}s"
+)

data/spec/integration/message_operations/partial_batch_delete_spec.rb

@@ -0,0 +1,67 @@
+# frozen_string_literal: true
+
+# This spec exercises Queue#delete_messages against a real partial batch-delete
+# failure (one valid receipt handle plus one invalid one).
+#
+# It confirms the end-to-end contract the NonRetryableException and AutoDelete
+# middlewares rely on: delete_messages returns a plain boolean true when any
+# entry fails, and a partial failure does not abort the rest of the batch (the
+# valid entry is still deleted).
+#
+# Note: the underlying bug (only the first failure was logged, and the truthy
+# return relied on Logger#error returning true) is only observable with a logger
+# that returns falsey, so it is reproduced in the unit specs. With the default
+# logger this path returns true either way - this spec guards the real-SQS
+# behavior of the rewritten method.
+
+require 'timeout'
+
+setup_sqs
+
+DT.clear
+
+queue_name = DT.queue
+create_test_queue(queue_name)
+queue_url = Shoryuken::Client.sqs.get_queue_url(queue_name: queue_name).queue_url
+
+# Send and receive a message so we hold a valid receipt handle.
+Shoryuken::Client.sqs.send_message(queue_url: queue_url, message_body: 'keep')
+
+received = []
+Timeout.timeout(15) do
+  loop do
+    received = Shoryuken::Client.sqs.receive_message(
+      queue_url: queue_url, max_number_of_messages: 1, wait_time_seconds: 1
+    ).messages
+    break if received.any?
+  end
+end
+valid_handle = received.first.receipt_handle
+
+# Batch-delete one valid handle and one bogus handle: a partial failure.
+queue = Shoryuken::Client.queues(queue_name)
+result = queue.delete_messages(
+  entries: [
+    { id: '0', receipt_handle: valid_handle },
+    { id: '1', receipt_handle: 'bogus-receipt-handle' }
+  ]
+)
+
+assert_equal(true, result, 'delete_messages should return true when any entry fails to delete')
+
+# The valid entry was still deleted; the partial failure did not abort the batch.
+remaining = nil
+Timeout.timeout(10) do
+  loop do
+    attrs = Shoryuken::Client.sqs.get_queue_attributes(
+      queue_url: queue_url,
+      attribute_names: %w[ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible]
+    ).attributes
+    remaining = attrs['ApproximateNumberOfMessages'].to_i + attrs['ApproximateNumberOfMessagesNotVisible'].to_i
+    break if remaining.zero?
+
+    sleep 0.3
+  end
+end
+
+assert_equal(0, remaining, 'the successfully-deleted message should be gone after the partial failure')

data/spec/integration/non_retryable_exception/non_retryable_exception_spec.rb

@@ -144,6 +144,6 @@ begin
   assert_equal(1, success_attempts.size, 'Successful message should only be attempted once')
   assert_equal(2, DT[:successful_processing].size, 'Both successful messages should be processed')
 ensure
-  launcher.stop
+  Timeout.timeout(30) { launcher.stop }
 end