Проверка доставки и очередей

Докажите техническую и продуктовую доставку, проверьте Horizon и найдите разрыв в цепочке

Что вы получите

Подключение будет проверено на трёх уровнях: доступ к провайдеру, реальное событие iEXExchanger и фактическое получение сообщения. Команда будет знать, где искать задержку и как безопасно восстановить отправку.

Три разных доказательства

1. Подключение

Сервер смог обратиться к SMTP, Resend или Telegram с сохранёнными параметрами.

2. Событие

Действие в заявке создало нужное событие, выбрало аудиторию и поставило работу в очередь.

3. Доставка

Сообщение появилось у правильного получателя и содержит ожидаемые данные.

Ни один из этих уровней не заменяет два остальных.

Проверьте E-mail-подключение

1

Откройте почтовое подключение

Проверьте адрес и имя отправителя, включение подключения и отметку сохранённого секрета.

2

Укажите контрольный адрес

Заполните «E-Mail для проверки» адресом, к которому у вас есть доступ. Не используйте реального клиента.

3

Нажмите «Отправить тест»

Форма сначала сохраняет текущие параметры, затем отправляет проверочное письмо. Если почтовый транспорт отклонил отправку, интерфейс должен показать ошибку, а не успешный результат. При успехе проверьте входящие, спам, имя и адрес отправителя.

4

Выполните «Проверить»

В списке подключений откройте действия строки и нажмите «Проверить». Сверьте новое состояние и время проверки.

Ответ провайдера «принято» означает только приём в обработку. Он не гарантирует папку «Входящие» и не подтверждает SPF, DKIM, DMARC или репутацию домена.

Проверьте коды входа по E-mail

Эта проверка обязательна, если в настройках обмена используется режим «Сначала подтвердить e-mail».

1

Получите первый код

На клиентском сайте используйте принадлежащий вам зарегистрированный адрес. Письмо должно быть принято транспортом, появиться в конечном ящике и содержать рабочий код.

2

Проверьте отказ первой отправки

В безопасном контрольном окне воспроизведите отказ тестового почтового подключения. Клиент должен увидеть ошибку отправки и не должен получить ложное сообщение об успешном коде.

3

Проверьте неудачную повторную отправку

Сначала получите рабочий код, затем воспроизведите отказ при запросе нового. После ошибки введите прежний неизрасходованный код: он должен оставаться действительным до обычного истечения.

Не ломайте рабочее почтовое подключение во время приёма клиентов. Для негативного сценария используйте отдельное контрольное подключение, согласованное окно или подготовленную среду.

Проверьте реальное событие

1. Создайте новую контрольную заявку с отдельным принадлежащим вам E-mail.
2. Выполните действие, которому соответствует одна строка матрицы.
3. Зафиксируйте ID заявки и время действия.
4. Проверьте правильного получателя, тему, язык, данные заявки и отсутствие секретов.
5. Убедитесь, что нежелательное второе подключение не создало дубль.
6. Повторите для клиентской и административной аудиторий.
7. После успешной проверки измените в матрице «Не проверено» на фактический результат.

Не переводите заявку клиента в ложный платёжный статус ради проверки. Используйте специально созданную контрольную заявку и меняйте статус только по согласованному сценарию.

Проверьте фоновые процессы

Уведомления обрабатываются тремя очередями:

• notifications-high;
• notifications-normal;
• notifications-low.

Откройте «Утилиты» — «Horizon и Pulse» — «Laravel Horizon». У сотрудника должно быть право на служебные ссылки панели.

Проверьте:

• работают ли отдельные обработчики каждой очереди;
• не растёт ли число ожидающих заданий;
• нет ли повторяющихся ошибок одного события;
• соответствует ли задержка назначенному приоритету;
• восстановились ли задания после кратковременной недоступности Redis или провайдера.

Планировщик регулярно подбирает неотправленные записи и служебные сводки. Поэтому исправный cron и работающие обработчики нужны даже тогда, когда проверка соединения прошла.

Ищите разрыв слева направо

Симптом	Где проверить сначала
Все каналы молчат	Главный переключатель и планировщик
Не работает только почта	Переключатель E-mail, подключение, DNS и провайдер
Проверочное письмо приходит, событие нет	Каталог событий, аудитория, модель получателя и очередь
Одно сообщение приходит дважды	Одинаковое событие в нескольких подключениях или повторная обработка
Telegram-бот найден, но чат молчит	Место доставки, права бота, аудитория и событие
В Horizon растёт очередь	Обработчики, Redis, ошибка задания и доступность провайдера
Провайдер принял, письма нет	Журнал провайдера, спам, bounce, SPF/DKIM/DMARC и репутация
Интерфейс сообщил об отправке, транспорт отказал	Повторная проверка подключения, журнал ошибки и фактический результат теста
Новый код не отправился	Введите прежний неизрасходованный код и восстановите почтовое подключение

Безопасное восстановление

1

Зафиксируйте границу отказа

Запишите подключение, событие, аудиторию, время и состояние очереди без копирования секрета.

2

Исправьте одну причину

Например, восстановите обработчик, исправьте адрес отправителя или замените отозванный ключ.

3

Повторите проверку подключения

Убедитесь, что состояние подключения снова корректно.

4

Создайте новое событие

Не считайте старую запись единственным доказательством. Вызовите новое безопасное событие и проверьте конечного получателя.

5

Проверьте отсутствие дублей

После восстановления убедитесь, что повторная обработка не отправила клиенту несколько одинаковых сообщений.

Этап завершён, если

• подключение проверено для каждого используемого канала;
• отказ почтового транспорта показывается как ошибка, а не как успех;
• первый и повторный E-mail-коды проверены, прежний код сохраняется при неудачной повторной отправке;
• реальное событие дошло каждой заявленной аудитории;
• проверены входящие, спам и журнал провайдера;
• три очереди обрабатываются без опасного накопления;
• повторная проверка не создаёт дублей;
• команда умеет найти разрыв по всей цепочке;
• после исправления проверяется новое событие, а не только старый статус.

Далее подготовьте почтовый домен и адреса.