Автоматизация бронирования: как мы восстановили отправку доступа

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

Пришлось отдельно проверить получение данных доступа, сохранение задания и ответы каналов отправки. Восстановление одной операции ещё не подтверждало выполнение остальных.

Почему обычная автоматическая обработка не подошла

Для одного посещения владелец согласовал нестандартный интервал доступа. Автоматическая проверка сравнивала его с обычными границами бронирования и не принимала такое сочетание.

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

Нам требовалось безопасно обработать согласованное исключение и проверить отправку информации нужному посетителю. Изменение условия отбора ещё не подтверждало передачу сообщения.

Почему комментарий к брони не стал надёжным местом для передачи

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

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

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

Как восстановили отправку

В проекте уже был механизм сохранённых заданий на доставку. Мы использовали его для конкретной брони: зафиксировали данные доступа и состояние ожидающей отправки, сохранив связанные параметры оплаты и посещения.

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

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

Как устроена задача, которая не теряется при перезапуске

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

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

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

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

Почему разные интеграции требуют разных проверок

Правила обмена у сервисов различаются. В документации YCLIENTS о webhooks указано, что система не выполняет повторные попытки отправки таких событий и не сохраняет статус их обработки получателем. Собственной системе нужно учитывать это при проектировании обмена.

У уведомлений ЮKassa другой порядок: сервис ждёт ответ HTTP 200 и при других ответах продолжает доставку в течение 24 часов с момента события. Эти правила относятся к входящим событиям сервисов. Отправка письма или сообщения посетителю остаётся отдельной операцией вашего приложения.

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

Что проверять при приёмке автоматической выдачи услуги

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

Что дать сотруднику поддержки

В обращении нужны номер бронирования внутри рабочей системы, состояние оплаты, время услуги и канал, по которому посетитель ожидает сообщение. Секреты доступа следует проверять в предназначенной для этого системе с установленными правами.

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

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