Подтверждение сообщает, что запрос принят
Первоначальный ответ на взаимодействие должен быть отправлен в течение трёх секунд после получения события. Это ограничение относится к реакции приложения, а не к обещанию закончить любую работу за три секунды. Если результат уже готов, его можно отправить сразу. Если требуется более длительная обработка, используется предусмотренное отложенное подтверждение. В библиотеке для Discord на Python такой переход представлен операцией defer. Она сообщает, что обработка продолжается. После этого приложение должно действительно завершить сценарий: передать результат или понятное сообщение об ошибке. Бесконечный индикатор ожидания не является корректным итогом. Подтверждение также не доказывает, что отчёт уже сформирован, файл сохранён или другое действие выполнено.
Первоначальный ответ нельзя отправлять заново
На одно взаимодействие допускается один первоначальный ответ. Поэтому после отложенного подтверждения нельзя обращаться с ним так, будто ответа ещё не было. Для продолжения используются изменение исходного ответа или последующее сообщение, в зависимости от выбранного сценария. Важно заранее определить, какой путь применяется в обычном завершении и при ошибке. Представим, что основной обработчик уже подтвердил команду, а общий обработчик исключений пытается отправить второй первоначальный ответ. Тогда к исходной ошибке добавится новая, связанная с неверным состоянием взаимодействия. Полезно рассматривать обработку как последовательность состояний: получено, подтверждено, завершено. Каждая ветка должна понимать, на каком этапе находится запрос, прежде чем выбирать способ ответа.
Время ожидания и повтор задачи требуют отдельного решения
Токен взаимодействия действителен ограниченное время: документация указывает пятнадцать минут для последующих ответов. Это не бессрочный канал связи. Если операция может длиться дольше, её жизненный цикл нужно продумывать отдельно и не считать первоначальное подтверждение вечным разрешением отвечать тем же способом. Также важно отличать сбой отправки сообщения от сбоя самой работы. Отчёт мог сформироваться, хотя пользователь не получил уведомление. Повторить всю операцию вслепую означает риск создать дубликат. В журнале полезно сохранять идентификатор запроса и его состояние, не записывая секретные значения. Для учебного бота сначала проверяют переходы на вымышленных данных и только затем связывают их с реальными действиями и необходимыми разрешениями.
Попробуйте на практике
Нарисуйте схему вымышленной команды, которая готовит отчёт за восемь секунд. Это бумажная модель: создавать бота, получать ключи или подключать сервер не требуется.
- Отметьте момент получения команды и необходимость первоначальной реакции до истечения трёх секунд. Выберите отложенное подтверждение для долгой обработки.
- Нарисуйте две ветки завершения: отчёт подготовлен и обработка закончилась ошибкой. Для обеих укажите, что первоначальная реакция уже отправлена.
- Добавьте ситуацию, когда отчёт готов, но уведомление не доставлено. Запишите необходимость проверить состояние работы перед её повторным запуском.
- Проверьте схему на дублирование первоначального ответа и бесконечное ожидание. Подпишите, какие состояния следует отражать в журнале.
Как проверить результат. В схеме есть один первоначальный ответ и понятный исход каждой ветки. Восемь секунд обработки не превращаются в восемь секунд молчания, а ошибка уведомления не объявляется доказательством отсутствия результата.
Частые вопросы
Отложенное подтверждение само отправит готовый результат?
Нет. Оно обозначает продолжение обработки. Приложению нужно отдельно завершить взаимодействие выбранным способом.
Можно ли одинаково отвечать на команду и любую ошибку?
Нужно учитывать текущее состояние. После первоначального ответа продолжение отправляется иначе; повторная попытка начального ответа может вызвать отдельную ошибку.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.