Диалог имеет состояние
Представим учебного бота для выбора времени консультации. У него есть этапы: выбор дня, выбор времени, проверка заявки и подтверждение. Ответ вторник имеет разный смысл, если бот сейчас спрашивает день или уже показывает итоговую запись. Поэтому сценарий описывают через текущее состояние, входящее событие и допустимый переход. Отдельно продумывают возврат назад, исправление выбора и непонятный ответ. Сообщение пользователю должно соответствовать реальному состоянию, а не просто следующему по порядку текстовому блоку.
Повтор события не всегда новое намерение
В Telegram входящее обновление имеет уникальный идентификатор update_id. Документация предусматривает использование этого идентификатора, чтобы распознавать повторные обновления. Если одно и то же событие подтверждения обработать дважды, наивный сценарий может попытаться повторить действие. Идентификатор обновления относится к доставленному событию. Второе отдельное нажатие пользователя способно породить другое событие, хотя смысл остаётся прежним: подтвердить ту же заявку. Поэтому полезно различать защиту от повторной обработки события и правило, запрещающее повторно создать уже подтверждённую заявку.
Ответ бота и результат операции различаются
Текст о завершении записи не доказывает, что она действительно сохранена. Если бот обращается к отдельной системе бронирования, результат должен быть проверен по данным этой системы. При задержке ответа нельзя автоматически считать операцию неудачной и бездумно создавать новую запись. В рабочей реализации обработку повторов, запись результата и одновременные запросы необходимо согласовать с используемым хранилищем. Бумажная схема выявляет требования, но сама по себе не обеспечивает надёжность сервиса. Для пользователя полезно предусмотреть понятный способ уточнить статус или обратиться к человеку.
Проверяйте неудобные последовательности
Обычный проход по кнопкам показывает лишь один вариант. Дополнительно проверяют повторное подтверждение, возврат к выбору времени, непонятный ответ и сообщение после завершения сценария. Запишите ожидаемое поведение до проверки, чтобы не объявлять любой результат приемлемым задним числом. Для учебной модели достаточно вымышленных дней и условного номера заявки. Настоящие имена, телефоны и иные сведения не нужны. В реальном проекте состав собираемых данных определяют по задаче, а доступ к служебным данным и секретам ограничивают.
Попробуйте на практике
Проверьте на бумаге сценарий подтверждения одной условной заявки.
- Нарисуйте четыре состояния: выбор дня, выбор времени, проверка заявки, подтверждено. Укажите допустимые переходы и возврат для исправления.
- Задайте заявку А: вторник, условное время 15:00. Переведите её на этап проверки без обращения к настоящему расписанию.
- Добавьте событие подтверждения с учебным идентификатором 71. Запишите единственное создание заявки и сохранённый результат.
- Повторите событие 71, затем добавьте отдельное событие 72 с повторным подтверждением заявки А. Для каждого объясните, какое правило предотвращает новую заявку.
- Добавьте неизвестный ответ и запрос проверки статуса. Укажите понятную реакцию бота и способ продолжения без выдуманного успешного результата.
Как проверить результат. Заявка А создаётся один раз. Повтор события 71 распознан по идентификатору, а событие 72 проверено по состоянию самой заявки. В схеме различаются сообщение пользователю, подтверждённая запись и ещё неизвестный исход операции.
Частые вопросы
Достаточно запомнить только последнее сообщение пользователя?
Нет. Одинаковый текст может относиться к разным этапам, а разные события к одной заявке. Нужны сведения о состоянии диалога и уже выполненных действиях.
Можно ли сначала сделать все кнопки, а повторы учесть потом?
Можно набросать интерфейс, но правила повторов и ошибок лучше определить до подключения реальных действий. Иначе удобный внешне диалог способен создавать дубли или сообщать неверный статус.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.