From 582083a7faa6f2bf50e11b2dbe4c821ecbb1a914 Mon Sep 17 00:00:00 2001 From: Your Name Date: Fri, 11 Sep 2026 22:51:58 +0930 Subject: [PATCH] Fix Redis queue retry_after being shorter than Horizon's timeout config/queue.php's redis connection defaulted retry_after to 90s, while config/horizon.php's supervisor-1 defaults to a 300s timeout in both environments. Per Horizon's documented timeout-chain requirement (job timeout < supervisor timeout < retry_after), this was backwards: any job legitimately running between 90s and 300s would get treated as dead by the queue driver and picked up by a second worker before Horizon's own supervisor had a chance to time it out, causing the same job to run twice concurrently. Bumps the default to 330s (a 30s margin over the supervisor timeout) and documents the relationship inline so it doesn't regress if either value is tuned later. --- config/queue.php | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/config/queue.php b/config/queue.php index e4b24ccce..780fef76f 100644 --- a/config/queue.php +++ b/config/queue.php @@ -68,7 +68,12 @@ return [ 'driver' => 'redis', 'connection' => env('REDIS_QUEUE_CONNECTION', 'default'), 'queue' => env('REDIS_QUEUE', 'default'), - 'retry_after' => (int) env('REDIS_QUEUE_RETRY_AFTER', 90), + // Must stay greater than Horizon's supervisor `timeout` + // (config/horizon.php, default 300s). Otherwise a job that's + // still legitimately running gets treated as dead and picked up + // by a second worker before Horizon has a chance to time it out + // itself, causing the same job to run twice concurrently. + 'retry_after' => (int) env('REDIS_QUEUE_RETRY_AFTER', 330), 'block_for' => null, 'after_commit' => true, ],