Очереди и планировщик

Фоновую работу стенда выполняют три контейнера на общем образе backend. Если какой-то из них лежит — приложение внешне работает, но «тихо» деградирует: не уходят уведомления, не строятся отчёты, не срабатывают автоматизации. При любых странностях с фоновой логикой первым делом проверяйте именно их.

Контейнер	Команда	За что отвечает
queue	queue:work --tries=3 --timeout=90	Основная очередь: email/Telegram-уведомления, индексация поиска, вебхуки
queue-reports	queue:work redis_reports --queue=reports --tries=1 --timeout=600 --memory=512 (с memory_limit=512M)	Только экспорт отчётов (XLSX/PDF/CSV) и рассылки по расписаниям
scheduler	schedule:work	Запуск регулярных задач приложения (см. ниже)

Почему отчёты — в отдельном воркере

Экспорт отчёта — долгая (до 10 минут) и тяжёлая по памяти задача: PDF на ~1000 строк потребляет ~350 MB. В общей очереди такие задания блокировали бы уведомления и убивали воркер по памяти. Поэтому:

• очередь reports живёт на отдельном соединении (redis_reports или database_reports — по драйверу стенда);
• воркер запущен с memory_limit=512M, --timeout=600, --tries=1;
• зависшие задания добивает reports:reap-stuck (см. ниже) — экспорт, «висящий» дольше 25 минут, помечается failed.

queue-reports обязателен

Если контейнер queue-reports не запущен, экспорты отчётов и рассылки по расписанию будут вечно стоять в статусе queued. Он входит во все compose-файлы — убедитесь, что он есть и в кастомных конфигурациях стендов.

Планировщик (scheduler)

schedule:work каждую минуту запускает задачи по внутреннему расписанию приложения:

Задача	Периодичность	Что делает
process:tasks	ежеминутно	Продвижение бизнес-процессов: таймеры, отложенные шаги
automations:run-scheduled	ежеминутно	Cron-автоматизации сущностей (например, пересчёт SLA)
imap:fetch	ежеминутно	Сбор входящей почты по всем настроенным ящикам
reports:run-due	ежеминутно	Запуск расписаний отчётов, у которых наступил cron-срок
reports:reap-stuck	каждые 5 минут	Помечает failed экспорты, зависшие сверх дедлайна (воркер умер/OOM)
tenant:backup	ежедневно 03:00	Логические бэкапы тенантов
license:check	ежедневно 06:00	Проверка лицензии, уведомления об истечении (подробнее)
reports:cleanup	ежедневно 04:30	Удаление файлов отчётов старше REPORTS_RUN_TTL_DAYS (30 дней)

Все задачи с withoutOverlapping — повторный запуск при ещё работающей копии пропускается.

Один scheduler на стенд

Контейнер scheduler должен быть ровно один. Два scheduler-а у одного стенда = двойной сбор IMAP (дубли обращений) и двойные запуски расписаний.

Диагностика

# Живы ли воркеры и что делают
docker ps --format 'table {{.Names}}\t{{.Status}}' | grep -E 'queue|scheduler'
docker logs orbita_onpremise_queue --since 10m
docker logs orbita_onpremise_queue_reports --since 10m   # имя по compose стенда
docker logs orbita_onpremise_scheduler --since 10m

# Очереди в Redis (глубина)
docker exec orbita_onpremise_redis redis-cli LLEN queues:default
docker exec orbita_onpremise_redis redis-cli LLEN queues:reports

# Проваленные задания
docker exec orbita_onpremise_backend php artisan queue:failed
docker exec orbita_onpremise_backend php artisan queue:retry all

Симптомы и их причины:

Симптом	Причина
Уведомления не приходят, поиск не находит новые записи	Лежит queue
Экспорты отчётов вечно queued	Лежит queue-reports
Экспорты падают в failed через ~25 минут	Воркер умирает в процессе (обычно OOM на PDF) — см. Типовые проблемы
Не собирается почта, не срабатывают расписания и таймеры процессов	Лежит scheduler
После обновления фоновая логика «старая»	Забыли queue:restart — см. Обновление

После изменения кода

Воркеры держат код в памяти. После каждого деплоя:

docker exec orbita_onpremise_backend php artisan queue:restart

queue:work завершится после текущего задания, и Docker (restart: always) поднимет воркер уже с новым кодом.