queue:work daemon enters infinite silent loop when getNextJob() throws non-database exceptions

[thuggins-engrain]

Laravel Version

11.46.0

PHP Version

8.2.27

Database Driver & Version

No response

Description

Worker::getNextJob() has a catch (Throwable) block with no retry limit. If the queue connection throws a non-database exception (e.g., SQS SDK timeout, auth error, HTTP failure), the worker enters an infinite loop: catch → sleep(1) → retry → catch → forever.

// Worker.php:372-378
} catch (Throwable $e) {
    $this->exceptions->report($e);
    $this->stopWorkerIfLostConnection($e);  // only checks DATABASE errors
    $this->sleep(1);
}

stopWorkerIfLostConnection() uses DetectsLostConnections which only matches MySQL/PostgreSQL/SQLite error strings. Queue connection failures (SQS, Redis, etc.) don't match, so shouldQuit is never set.

The worker also has no pcntl_alarm active during getNextJob() — the timeout handler is only registered during runJob() and cleared at resetTimeoutHandler() before the next call.

Impact: Worker container stays "Up" but processes zero messages indefinitely. In production we observed 4 of 7 workers stuck in this state for days.

Steps To Reproduce

Steps To Reproduce

1. Run php artisan queue:work --queue=any-queue with a queue driver that throws on pop() (e.g., SQS with invalid credentials, or a mock driver)
2. Worker loops forever in getNextJob() catch block
3. --timeout, --memory, and --max-time do not stop it

[thuggins-engrain]

Suggested fix: Add a consecutive failure counter that exits the worker after a threshold:

} catch (Throwable $e) {
    $this->exceptions->report($e);
    $this->stopWorkerIfLostConnection($e);
    $this->consecutiveGetNextJobFailures = ($this->consecutiveGetNextJobFailures ?? 0) + 1;
    if ($this->consecutiveGetNextJobFailures >= 100) {
        $this->shouldQuit = true;
    }
    $this->sleep(1);
}

Reset the counter when getNextJob() succeeds. Transient errors recover, infinite loops don't.

Alternatively, stopWorkerIfLostConnection() could be broadened to detect queue connection failures, not just database ones.

[macropay-solutions]

Hi. If the worker stops and restarts, the errors are solved?

[thuggins-engrain]

Yes — restarting the worker resolves it. The problem is that the worker doesn't stop on its own. After the initial error, getNextJob() catches the Throwable, logs it, sleeps 1 second, and loops back to getNextJob() again — indefinitely. There's no retry limit or circuit breaker, so the worker stays alive but
never recovers.

In our case (Docker containers with restart: on-failure), if the process exited, Docker would restart it and it would come back healthy. But because the catch(Throwable) loop never exits, the container appears "Up" while doing nothing useful. We've had to manually SSH in and restart them.

The ask is for some kind of escape hatch in the getNextJob() catch — e.g., a consecutive failure counter that calls $this->stop() after N failures, so the worker exits and can be restarted by the process supervisor.

[webpatser]

Hey @thuggins-engrain — I took a stab at this with #59553, adding a --max-pop-exceptions option that would exit the worker after N consecutive pop failures. Unfortunately Taylor closed it — framework scope and all that.

If you need a fix now, your best bet is wrapping the logic in a custom worker command or a package. The approach from the PR (consecutive failure counter + reset on success) works well in practice. Happy to share the code if that helps.