Queue worker exits prematurely with --max-time due to incorrect $startTime in pauseWorker path

[hectorjazz]

Laravel Version

11.45.1

PHP Version

8.2.6

Database Driver & Version

No response

Description

When the queue:work worker is run with the --max-time option and enters a paused state (e.g., during maintenance mode), it exits prematurely.

The root cause is in the Illuminate\Queue\Worker class. The pauseWorker method calls the stopIfNecessary method but fails to pass the required $startTime argument.

As a result, $startTime receives its default value of 0 inside stopIfNecessary, causing the max-time check to pass immediately and the worker to terminate.

The fix is to correct the call in pauseWorker to properly propagate the $startTime argument to stopIfNecessary, ensuring the runtime is calculated correctly.

Steps To Reproduce

1. Put the Laravel application into maintenance mode:
   php artisan down
2. Run the queue worker with any --max-time limit:
   php artisan queue:work --max-time=3600
3. Observe the output. The worker process will exit after the first cycle (e.g., after the sleep duration) instead of continuing to run for the specified max time.

The expected behavior is for the worker to pause and continue its loop, respecting the --max-time limit, even while the application is in maintenance mode.

[crynobone]

Observe the output. The worker process will exit after the first cycle (e.g., after the sleep duration) instead of continuing to run for the specified max time.

If the application is set to maintenance and queue are paused and expected to continue after maintenance ended the queue might be running on an older version of the code and that might leads to additional errors/issues.

[rodrigopedra]

If the application is set to maintenance and queue are paused and expected to continue after maintenance ended the queue might be running on an older version of the code and that might leads to additional errors/issues.

If code was updated, one should call php artisan queue:restart after deploying to ensure the new code is being used anyway.

I have a custom Looping observer that returns false upon a queue being rate limited to avoid attempting and needlessly re-enqueueing endless jobs at the end of the queue before the rate limit timeouts.

I had to remove the max-time from my workers, as they were stopping instead of waiting.

[howdu]

Not sure if it's the same issue, but I recently ran into a similar issue where the queue worker began exiting unexpectedly.

Traced it back to a recent change in Symfony OutputFormatter.php, specifically the formatAndWrap changes.

Still not entirely sure what the root cause is with those changes because the output is identical.

[crynobone]

one should call php artisan queue:restart after deploying to ensure the new code is being used anyway.

I would assume not everyone would be doing it and this could be a big breaking changes for some. Might be worth to make the changes for Laravel 13 and have a big warning on the upgrade guide.

[rodrigopedra]

one should call php artisan queue:restart after deploying to ensure the new code is being used anyway.

I would assume not everyone would be doing it and this could be a big breaking changes for some. Might be worth to make the changes for Laravel 13 and have a big warning on the upgrade guide.

@crynobone, this procedure is recommended in the docs.

First here:

Remember, queue workers are long-lived processes and store the booted application state in memory. As a result, they will not notice changes in your code base after they have been started. So, during your deployment process, be sure to restart your queue workers.

Reference: https://laravel.com/docs/12.x/queues#running-the-queue-worker

Then here:

Since queue workers are long-lived processes, they will not notice changes to your code without being restarted. So, the simplest way to deploy an application using queue workers is to restart the workers during your deployment process. You may gracefully restart all of the workers by issuing the queue:restart command

Reference: https://laravel.com/docs/12.x/queues#queue-workers-and-deployment

Disclaimer: Bolds are mine.

Thus, I don't think we need to wait for a new version to fix this unexpected behavior.

[crynobone]

I'm not 100% sure if everyone would assume that php artisan down and php artisan up are always considered a new deployment.

Feel free to submit a PR and let Taylor decide.

[rodrigopedra]

I'm not 100% sure if everyone would assume that php artisan down and php artisan up are always considered a new deployment.

Me neither.

I might have misunderstood you here, but I meant the opposite.

I meant that on a new deployment, it is always advisable to run php artisan queue:restart, on projects that run queues.

Running php artisan down and php artisan up should not be considered a new deployment, IMO.