Почему бот теряет уведомления и как это проверить до запуска

Разделите заявку и сообщение о ней

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

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

Согласуйте понятные состояния

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

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

Различайте временные и постоянные ошибки

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

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

Не превращайте повтор в новый заказ

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

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

Учитывайте входящие события

Боту нужно не только писать, но и получать ответы. Telegram предоставляет два основных механизма получения обновлений, и входящие события не хранятся платформой бесконечно. Официальная документация указывает предельный срок хранения до получения — не более двадцати четырёх часов. Поэтому длительный простой нельзя считать безобидной паузой, после которой любой разговор обязательно восстановится сам.

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

Проведите испытание с отключённым каналом

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

Отдельно проверьте неправильный адрес получателя, блокировку бота и сообщение, которое больше не актуально. Сотрудник должен увидеть проблему без чтения программного кода. Хорошая демонстрация заканчивается не словами «ошибка обработана», а понятным экраном или отчётом: вот заявка, вот причина задержки, вот доступное действие. Так можно оценить качество ещё до подключения реальных клиентов.

Договоритесь о сопровождении

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

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

Что проверить в своей задаче

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