enВойти в Senler

Повторная доставка вебхуков

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

Повтор и закрытие инцидента

В выбранной операции проверьте детали запроса: исходный JSON, HTTP-ответ или сетевую ошибку. Ниже находится список попыток с временем и результатом каждой доставки. Сначала устраните причину ошибки, затем выберите нужное действие:

  • «Отправить повторно» ещё раз отправляет сохранённый запрос на URL webhook. Ответ остаётся в журнале и сам по себе не продолжает работу ожидающего агента.
  • «Отправить повторно и передать ответ агенту» доступно для инструмента в режиме ожидания результата, если операция связана с агентом и её можно повторить. После успешного ответа результат передаётся ожидающему агенту для продолжения работы.
  • Если повтор не нужен, отметьте проблему решённой. Она исчезнет из числа нерешённых, но запрос не будет отправлен заново, а история сохранится.
Повтор и закрытие инцидента. Отмеченные элементы: 1. детали запроса; 2. «Отправить повторно»; 3. «Отправить повторно и передать ответ агенту»; 4. отметьте проблему решённой
1. детали запроса · 2. «Отправить повторно» · 3. «Отправить повторно и передать ответ агенту» · 4. отметьте проблему решённой

Повтор доступен только для ещё не решённой операции со статусом повтора или ошибки. Обычно требуется incident.retryable: true. Отдельное исключение — внешний обработчик ответил HTTP 401 или 403: после исправления авторизации или прав доступа запрос можно отправить вручную даже при retryable: false. Надпись «Автоматический повтор недоступен» не запрещает этот ручной повтор. Для ошибки внутри платформы исключение не действует.

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

Перед подтверждением учтите защиту от дублей. Ручной повтор создаёт новую операцию доставки, но сохраняет исходный event_id; timestamp в теле обновляется, остальные данные остаются прежними. Автоматические попытки также сохраняют event_id, но обновляют timestamp тела и заголовка при каждой отправке. Поэтому на стороне обработчика определяйте дубли по event_id, а не по времени или полному совпадению JSON. Если действие уже выполнено, не создавайте заказ или сообщение повторно; для инструмента верните ранее полученный результат в ожидаемом формате.

Несколько операций

Для нескольких нерешенных операций отметьте все загруженные или выберите строки вручную. Повторно отправить можно до 25 выбранных запросов за одно действие; каждый должен допускать ручной повтор. Для каждого создаётся отдельная операция с его исходным event_id. Отметить выбранные решенными можно для выборки до 100 запросов. Действие «Отметить решенными все по фильтру» обрабатывает до 1000 совпадений; если их больше, сузьте фильтр.

Закрытие инцидента

При закрытии выберите причину и оставьте комментарий от 10 до 1000 символов. Для обычной проверки используйте reviewed, если исправление не требовалось, или fixed, если причина устранена. Для специальных случаев доступны obsolete, superseded, invalid_payload, accepted_loss, task_completed, diagnostic_completed, replay_cancelled и webhook_deleted. Код причины сохраняется как resolution_code, комментарий — как resolution_comment; агент может использовать оба поля, чтобы отличить рассмотренный инцидент от действительно исправленного.

Операции хранятся 90 дней, нерешенные ошибки — до решения, а отдельные попытки доставки — 365 дней. Отметка «Решено» не удаляет историю и не отправляет запрос повторно; она только исключает проблему из числа нерешенных.