Разделите три проверки
- Веб-приложение
- Принимает запрос пользователя и возвращает страницу или ответ API.
- Очередь и обработчик
- Задание попадает в очередь, а отдельный процесс должен его получить и выполнить.
- Планировщик
- Запускает действия по расписанию. Такое действие, в свою очередь, может отправить задание в очередь.
Из этой схемы следует практическое правило: если задача по расписанию не выполнена, нужно выяснить, была ли она вообще запущена и дошло ли её задание до обработчика.
Найдите конкретное задание
Начните с одного примера: письмо по определённому заказу, импорт файла или синхронизация статуса. Зафиксируйте время и идентификатор события. Вопрос "все ли письма не приходят" слишком широкий для первого шага.
- Создалось ли задание после нужного действия?
- В какое подключение и какую очередь оно отправлено?
- Есть ли обработчик именно для этой очереди?
- Задание ожидает, завершилось или попало в ошибки?
Возможности выбора очередей, работы обработчиков и разбора неуспешных заданий описаны в документации очередей Laravel. Команды и конфигурацию нужно сверять с версией вашего проекта.
Проверьте обработчик
Длительно работающий обработчик очереди сохраняет загруженное приложение в памяти. После обновления файлов он может продолжать использовать прежний код. Поэтому порядок выпуска должен учитывать обновление этих процессов. Это отдельно отмечено в разделе обработчики очередей и деплой.
Нужно проверить и сам процесс: запущен ли он, в каком окружении работает, имеет ли доступ к нужному хранилищу очереди и кто запустит его снова после завершения. Наличие команды запуска в старой инструкции ещё не подтверждает, что процесс сейчас работает.
Не перезапускайте несколько обработчиков вслепую. Сначала выясните, какие задания уже выполняются и допускают ли они повтор: повторное письмо и повторный платёж имеют разные последствия.
Проверьте расписание
В типичной схеме Laravel системное расписание регулярно вызывает планировщик приложения. В официальном примере такой вызов выполняется раз в минуту. Если его нет или он запускается в другом окружении, задача не начнётся по ожидаемому времени. См. запуск планировщика Laravel.
Сопоставьте время сервера, заданное расписание, вывод команды и журналы приложения. Если задание создаёт работу для очереди, продолжите проверку до результата этой работы, а не останавливайтесь на отметке о запуске планировщика.
Проверьте результат
В проверку релиза полезно включить одно понятное фоновое действие и убедиться, что получен его результат: письмо отправлено, файл обработан или статус изменён. Это проверяет больше, чем простой запуск главной страницы.
Службы, живущие дольше одного запроса, должны быть учтены в процессе выпуска. А отладочную информацию на рабочем сайте не следует открывать посетителям. Оба вопроса разобраны в руководстве Laravel по развёртыванию.
Что передать для разбора
Версию Laravel, время и пример задачи, подключение очереди, сведения о способе запуска обработчика и последнем релизе. Секреты окружения в открытое сообщение не включайте.
Если нужно организовать процесс целиком, посмотрите настройку инфраструктуры и деплоя. Если проблема находится в логике задания или обмене данными, может понадобиться доработка интеграции.