A missing retry_after key hands a running Laravel job to a second worker

On Redis, the reservation is a score in a sorted set. One Lua script does the whole pop: it lpops the payload off the ready list, increments the payload's attempts counter, and zadds the result to the reserved set with a score of now plus retry_after ^[11]. Nothing watches that score. The cleanup happens on the next pop of the same queue, which calls migrate() first, and migrate() moves two things back onto the ready list: delayed jobs that have come due, and reserved jobs whose lease has run out ^[12]. According to the dev.to write-up, migrate() cannot tell a job whose worker was killed by a deploy from a job whose worker is still running it, because both are an expired score ^[13].

The two clocks do not start together. The lease begins at pop(), and the worker's timeout alarm is armed a few steps later, so matching values mean the reservation always expires first ^[7]. retry_after belongs to the queue connection and sets how long a reservation is honoured; timeout belongs to the worker and bounds how long one job may occupy a process ^[16].

The 90 in a stock skeleton is a line in your configuration file, not a framework default. The Redis connector reads Arr::get($config, 'retry_after', 60) ^[6]. A second Redis connection written by hand for a dedicated queue, or one built inside a test, gets 60 against a 60-second worker timeout, which is zero slack ^[1]. That connection passes review without comment and is wrong from the first job that runs long ^[15]. The 60/90 pairing describes an untouched skeleton, and timeout can also be set on the job class itself ^[1], so a team that has tuned one job has to check that job rather than the shipped numbers.

Which symptom you get is decided by a third number in a third place. Horizon's published config ships tries => 1 ^[8]. The script increments attempts on every pop, so the second reservation puts the job at two attempts against a limit of one, and work that finished is recorded in failed jobs with MaxAttemptsExceededException ^[2]. Set tries to 2 or more and both workers run the job to completion, both report success, and nothing is recorded ^[9]. The database driver reaches the same outcome through SQL instead of a sorted set, in isReservedButExpired() ^[14].

The ordering the post gives is job timeout < supervisor timeout < retry_after, with margin at each step, and it says nothing in Laravel tells you when that ordering stops holding ^[10]. The margin has to cover the worker timeout plus whatever the process spends between the pop and the alarm being armed ^[7]. No check runs at boot, at dispatch, or when a supervisor starts a worker ^[2], so the cheap version is a test that walks config('queue.connections') and asserts each retry_after is larger than the timeout of the workers running on it.