PHP и Laravel
Laravel: задания остаются в очереди и не выполняются
Laravel принимает задания, но очередь не движется. Объясняем, кто должен их выполнять и как проверить запуск без массового повтора ошибок.
Что происходит и с чего начать
Постановка задания и его выполнение — разные события. Приложение может сохранить job в очереди, но отдельный процесс worker должен забрать её и обработать. Если он остановлен или слушает другое имя очереди, данные будут накапливаться без видимой ошибки формы. Поэтому сначала проверьте, где находится задание и меняется ли его состояние. Не запускайте множество workers наугад: они могут начать одновременно выполнять старые операции, которые уже не следует повторять без сверки.
Что можно проверить самостоятельно
- Запишите тип задания, время создания и имя очереди, если оно известно. Проверьте, растёт ли список ожидающих или появляются записи о неудачных попытках выполнения.
- Уточните, кто запускает worker и перезапускает его после сбоя или публикации. Вручную открытая команда в терминале не гарантирует постоянную работу после закрытия соединения.
- Сообщите, что должно происходить в задании: письмо, обмен, создание документа. Перед повтором старых задач проверьте, не выполнена ли часть действий во внешнем сервисе.
Как понять результаты проверки
Специалист проверяет подключение к хранилищу очереди, имена очередей и окружение процесса. Долгоживущий worker может использовать прежнюю конфигурацию после изменения файлов. Также важны ограничения времени и число попыток. Повторная обработка не должна бездумно повторять внешнее действие, если оно успело выполниться до ошибки. Поэтому запуск очереди и безопасное восстановление её накопившихся заданий — связанные, но разные задачи. Нужен понятный список того, что выполнится после возобновления работы.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Сверьте очередь, куда отправляется job, с параметрами запущенного worker. Проверьте выбранный драйвер и окружение процесса.
- Посмотрите журнал менеджера процессов, неудачные задания и исключения. Отличайте неработающий worker от задания, которое сразу падает и повторяется.
- Проверьте доступность Redis или базы, лимиты памяти и тайм-ауты. После деплоя долгоживущий процесс может продолжать выполнять старый код.
На что обратить внимание
Задания могут накапливаться в одной именованной очереди, пока процесс слушает другую. В этом случае перезапуск без проверки параметров ничего не меняет.
Как исправляют причину
Запустите правильный worker под менеджером процессов и настройте его восстановление. Неудачные задания повторяйте после устранения причины и проверки побочных эффектов. Процедура деплоя должна обновлять долгоживущие процессы.
Как убедиться, что проблема решена
Отправьте контрольное задание и проследите переход от постановки к завершению. Затем проверьте восстановление после перезапуска и отсутствие повторной отправки уже выполненного уведомления.
Создайте новое контрольное задание и проследите его до результата. Затем проверьте автоматический запуск worker после согласованного перезапуска службы. Старую очередь восстанавливайте по состояниям и назначению задач. Приёмка должна подтверждать не только исчезновение записей из ожидания, но и корректный бизнес-результат: письмо доставлено провайдеру, данные приняты, документ создан без повторного побочного действия.