Как восстановить SMS-интеграцию и не отправить старые сообщения

Приостановите отправку из очереди, проверьте срок актуальности сообщений и отделите новые задания от тех, чей результат неизвестен. После сбоя сервера простой перезапуск SMS-интеграции рискует отправить клиентам старые коды, напоминания о прошедших встречах или повторные уведомления о заказе. Ниже разберём, как проверить очередь, сопоставить ответы SMPP-шлюза со статусами доставки и возобновить отправку под контролем. Этот порядок подходит и для небольшой очереди из сайта, и для интеграции через API или SMPP.

Что остановить перед восстановлением SMS-интеграции?

Сначала остановите обработчики, которые забирают задания из очереди и передают их SMS-провайдеру. Сам сайт при этом может продолжать принимать заказы. Если приложение создаёт новые уведомления, пусть они остаются в очереди до проверки правил отправки.

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

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

Рабочая последовательность для разработчика:

1. Приостановить получение заданий всеми обработчиками отправки.
2. Зафиксировать запросы, для которых приложение не получило ответ.
3. Сохранить состояние очереди и журнал событий перед изменениями.
4. Проверить соединение со шлюзом отдельно от массовой отправки.

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

Как определить, какие SMS уже нельзя отправлять?

Для каждого задания нужны время создания, срок актуальности и связь с событием в бизнесе. Возраст сообщения сам по себе ничего не решает. Уведомление о готовности заказа ещё может быть полезно, а напоминание о встрече после её начала уже потеряло смысл.

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

• Код подтверждения: срок действия ещё не истёк, код не использован и не заменён новым.
• Напоминание о записи: встреча ещё впереди, клиент её не отменил и не перенёс.
• Уведомление о заказе: событие всё ещё соответствует текущему состоянию заказа.
• Рекламное предложение: условия и срок предложения ещё действуют.

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

Устаревшее задание помечайте с конкретной причиной: «срок истёк», «запись отменена» или «событие заменено новым». Не возвращайте его в очередь после очередного перезапуска. При этом новое состояние заказа не всегда требует новой SMS: сначала проверьте, не отправляли ли уведомление об этом событии раньше.

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

Что делать с SMS, для которых нет ответа шлюза?

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

В SMPP сохраняйте ответ submit_sm_resp и идентификатор сообщения, который вернул шлюз. Успешный ответ означает, что шлюз принял запрос, но ещё не подтверждает доставку клиенту. Итог отслеживают отдельно через DLR, то есть отчёт о доставке. Разницу между этими этапами разбирает материал как проверить доставку SMS в SMPP и найти источник задержки.

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

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

Если API поддерживает ключ идемпотентности, уточните его действие и срок у провайдера. При повторе тот же ключ позволяет сервису распознать прежний запрос в пределах своих правил. Не переносите это ожидание на SMPP: наличие внутреннего ключа в приложении не означает, что шлюз умеет исключать дубли по нему.

Как возобновить отправку без повторного сбоя?

После проверки очереди запускайте отправку с ограничением скорости. Не пытайтесь сразу передать весь накопленный объём. В разборе стоимости SMS через SMPP описана конкретная ошибка: рекламный поток без ограничения скорости задерживает сервисные сообщения (источник: smpp.by, «Как снизить стоимость SMS через SMPP без потери доставки»).

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

1. Проверьте сценарий восстановления в тестовой среде: просроченное задание должно завершиться без отправки, повторное событие не должно создать дубль.
2. Запустите ограниченную отправку актуальных сообщений и проверьте ответы шлюза.
3. Сопоставьте эти задания с DLR и убедитесь, что обработчик статусов работает после перезапуска.
4. Повышайте скорость, пока очередь сокращается без роста ошибок и задержек.

Подготовить проверку поможет материал как протестировать SMS-интеграцию без платных отправок. Тестовая среда позволяет проверить логику очереди, но фактическую доставку через рабочий маршрут нужно проверять отдельно.

Во время запуска следите за долей доставленных сообщений, временем ответа API или SMPP, числом ошибок и задержкой DLR. Такой набор показателей помогает искать сбой в приложении, очереди или на маршруте доставки (источник: smpp.by, «Как настроить мониторинг SMS-интеграции в 2026 году»). Дополнительно смотрите на возраст самого старого актуального задания: очередь должна успевать отправлять SMS до истечения их срока.

Если интеграцию сопровождает подрядчик, включите в задачу проверку очереди и обработчика DLR, а не только восстановление соединения. При выборе SMPP-шлюза или API-интеграции уточняйте, какие журналы и средства аналитики помогут разобрать запрос с неизвестным результатом.

Типичные ошибки при восстановлении SMS-интеграции

• Перезапустить все обработчики сразу. Несколько процессов одновременно начнут отправку; сначала проверьте, кто получает задания из очереди.
• Повторить каждый запрос без ответа. Шлюз мог уже принять сообщение; сначала восстановите его результат по доступным журналам.
• Оценивать актуальность только по дате создания. Проверьте также текущее состояние заказа, записи или кода.
• Считать успешный submit_sm_resp подтверждением доставки. Для вывода о доставке дождитесь соответствующего DLR.
• Повторять отправку после любой ошибки. Разделите временные сбои и постоянные причины отказа; неверный номер или запрещённый формат не исправятся от повтора.

Начните с действия на две минуты: откройте очередь и проверьте у одного старого задания, есть ли срок актуальности. Если такого поля нет, запишите задачу разработчику: «Перед отправкой проверять срок действия SMS и завершать просроченные задания без передачи шлюзу».