Дубли заявок у бота могут появляться при повторной доставке события, повторном нажатии пользователя или повторе запроса к CRM. Защита требует идентификаторов событий и бизнес-операций, надёжного сохранения состояния и отдельного правила для неизвестного результата. Очередь обработки помогает пережить сбой, но её настройка сама по себе не исключает дубли.
Владелец бизнеса должен убедиться, что одна намеренная заявка создаёт один согласованный результат. При этом новая заявка того же человека должна оставаться новой, если он действительно обращается по другому вопросу.
Почему платформа присылает событие снова
Telegram отправляет обновления на webhook, адрес обработчика вашего бота. Если ответ запроса имеет код, отличный от 2xx, платформа повторяет доставку. В документации также описан update_id, идентификатор обновления, который помогает распознавать повторы. Telegram Bot API: setWebhook и Update.
Поэтому повтор одного обновления относится к штатным условиям интеграции. Обработчик может получить данные, сохранить заявку и остановиться до отправки успешного ответа. Для Telegram это выглядит как неудачная доставка. Следующая попытка принесёт те же данные.
С очередями тоже следует читать условия доставки. Например, стандартные очереди Amazon SQS допускают повторное получение сообщения и требуют подходящей обработки повторов. Amazon SQS: доставка как минимум один раз.
Различайте три вида повторов
| Ситуация | Что совпадает | Предлагаемое правило |
|---|---|---|
| Платформа повторила событие | Идентификатор обновления | Вернуть результат прежней обработки |
| Пользователь дважды нажал кнопку | Одна операция формы, разные события | Проверить идентификатор заявки и её состояние |
| Человек отправил новый запрос | Контакт прежний, намерение новое | Создать новое обращение, связать с контактом |
Таблица показывает рекомендуемые правила проектирования. Номер телефона пригоден для поиска контакта, но плохо заменяет идентификатор события. Запрет всех повторных обращений с одного телефона способен скрыть настоящий спрос.
Для нескольких ботов или каналов добавьте к идентификатору события источник. Нельзя предполагать, что номера из разных независимых систем никогда не совпадут.
Что означает идемпотентность
Идемпотентная обработка означает, что повтор той же операции не создаёт дополнительного результата. Для заявки это может быть возврат уже созданного номера. Для метки идемпотентная обработка сохраняет согласованное состояние.
AWS Builders' Library описывает подход с уникальным идентификатором запроса, который сохраняет намерение клиента при повторе. Там также отмечена необходимость согласованно записывать идентификатор и результат операции. AWS: безопасные повторы API.
Рекомендуем проверять существование идентификатора и записывать операцию атомарно, в одном защищённом шаге. Иначе два параллельных обработчика успеют одновременно увидеть «такой заявки нет» и создать по записи. Простая последовательность «найти, затем добавить» без защиты от конкуренции остаётся уязвимой.
Путь заявки со статусами
Полезно разделить приём, обработку и внешний результат. Событие сначала надёжно сохраняется. Затем задача поступает исполнителю. Если база и очередь отдельные, предусмотрите повторную постановку сохранённых задач или их выборку исполнителем. Иначе сбой между этими шагами оставит принятую заявку без обработки. После создания записи в CRM фиксируется её внешний идентификатор. Подтверждение клиенту отправляется по отдельной операции.
Пример рекомендуемых статусов: получено, сохранено, обрабатывается, передано в CRM, подтверждение отправлено, ошибка для разбора. Для каждого перехода определите, кто его выполняет и какие данные доказывают завершение.
Успешный ответ платформе стоит возвращать после надёжного сохранения события. Конкретный механизм выбирает разработчик: запись в базе или подтверждённая запись в устойчивой очереди. Если подтвердить приём до сохранения, остановка процесса может привести к потере. Если держать webhook открытым на время длинной обработки, повышается зависимость от тайм-аутов.
Самый сложный случай: CRM ответила неизвестно
Условный пример: запрос на создание заявки дошёл до CRM. Ответ потерялся из-за сетевого сбоя. Бот видит тайм-аут и не знает, создана ли карточка.
Если CRM поддерживает ключ операции, повтор должен использовать прежний ключ. Если есть поиск по внешнему идентификатору, сначала проверяют наличие карточки. Возможности зависят от конкретного API.
Если внешняя система не позволяет ни безопасный повтор, ни надёжную проверку, результат переводят в состояние «требуется сверка». Автоматическое повторение с новым ключом может создать дубль. В интерфейсе сотруднику нужны время, источник, идентификатор операции и причина неопределённости.
Необратимые внешние действия проверяют отдельно. Наличие идемпотентной входной обработки ещё не доказывает, что повторная отправка уведомления исключена.
Какие испытания заказать разработчику
До запуска рекомендуем проверить несколько сценариев на тестовых данных:
- Одно и то же обновление приходит последовательно и одновременно. Создаётся одна заявка.
- Пользователь повторно нажимает кнопку отправки. Он получает номер уже принятой операции.
- Тот же пользователь создаёт другую заявку. Новое обращение сохраняется.
- Процесс останавливается после сохранения, затем продолжает работу. Заявка доходит до следующего этапа.
- CRM создаёт запись, но соединение прерывается до ответа. Система сверяет результат по предусмотренному правилу.
- Очередь недоступна. Бот не сообщает об успешном приёме несохранённых данных.
Для каждого испытания приложите журнал и фактические записи. Скриншот ответа бота подтверждает внешний текст, сохранность данных проверяется отдельно.
Что видеть в рабочем отчёте
Полезны число принятых событий, количество распознанных повторов, возраст самой старой необработанной заявки и число неопределённых результатов. Назначьте сотрудника, который разбирает последние два показателя.
Порог уведомления выбирают под процесс. Длительная задержка может сорвать запись на ближайшее время. Для запроса справки допустимый срок ожидания может быть больше. Запишите ожидаемое время обработки и порядок ручной работы при сбое.
Такая схема позволяет объяснить судьбу конкретной заявки. Когда клиент спрашивает, принят ли запрос, сотрудник может найти операцию и её состояние, затем выполнить точное действие по восстановлению.
Источники
- Telegram Bot API: повтор доставки и идентификатор обновления.
- Amazon SQS: возможность повторного получения сообщения.
- AWS Builders' Library: ключи запросов и идемпотентность. Статусы и приёмочные испытания предложены редакцией.