Пропущенные webhook: как восстановить записи в CRM без дублей

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

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

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

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

Для своей интеграции выясните срок хранения истории, идентификаторы событий, возможность запросить актуальный объект, ограничения API и механизм повторного запроса. Не стройте регламент на предположении «сервис когда-нибудь пришлёт ещё раз». Если история недоступна, потребуется другой способ сверить известные записи и обнаружить пропуски.

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

Определите владельца каждого поля. Например, календарь может управлять датой визита, а CRM — заметкой менеджера. Восстановление не должно копировать объект целиком поверх всех полей: так можно удалить более свежую работу сотрудника, которая не относится к произошедшему сбою.

Разделите обновление текущего состояния и выполнение действий. Возврат правильной даты в CRM не требует снова отправлять старое приглашение, создавать ещё одну задачу или инициировать платёж. Для каждого эффекта нужен собственный способ установить, выполнялся ли он и следует ли его выполнять сейчас.

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

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

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

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

При обсуждении MySlot запросите контракт событий и способы получить актуальное состояние брони, список изменений и историю отмен. Уточните, какие данные доступны для восстановления и как ведут себя повторные запросы. Если нужных методов нет, объём автоматической сверки ограничен; это следует зафиксировать до запуска, а не компенсировать обещаниями полного восстановления.