События
Журнал доставок
Состояния доставки, чтение тела события и повтор ошибочных вручную.
На этой странице · 6
Журнал доставок на экране «Вебхуки» отвечает на вопрос «что именно ушло и чем это кончилось». Каждая строка — одна попытка доставки одного события: состояние, код ответа, время ответа, получатель и сырое тело запроса.
Состояния доставки
Различие failed и no_response не косметическое. failed значит, что ваш
обработчик ответил — и ответил не тем; смотрите код ответа и текст ошибки.
no_response значит, что ответа не пришло: приложение не поднято, порт закрыт,
обработчик завис или агент умер, не успев ответить. Без отдельного состояния
такая доставка навсегда висела бы в «попытка 1 из 5», что для инструмента,
где человек сидит и ждёт событие, — худший класс поведения.
Зависшие доставки подбирает планировщик: если ответа нет дольше таймаута сервиса
плюс пятнадцать секунд, доставка переводится в no_response с пояснением
«Ответ не получен в отведённое время».
Типичные причины
Текст причины для http_error пишется словами сервиса: Код ответа 500,
STATUS_CODE_NOT_OK: получен 204, EMPTY_BODY: пустое тело ответа,
WRONG_RESULT_FIELD: ожидалось {"result": true}.
Попытки
В шапке панели «Тело события» стоит «попытка N из M». Знаменатель — из профиля сервиса: 1 у Bitrix24, 11 у Ozon, 6 у Wildberries. Единица у Bitrix24 — не недоделка, а его поведение: повторов у сервиса нет.
Каждая попытка не создаёт новой строки — счётчик растёт в той же. Поэтому время в строке — это время последней попытки, а не первой.
Сырое тело против разобранного
В базе хранится сырое тело запроса как строка. Иначе и нельзя: у Bitrix24
это application/x-www-form-urlencoded, и JSON-колонка здесь была бы ошибкой.
Панель «Тело события» показывает это тело читаемо:
application/json— с отступами, черезJSON.parseи обратно;application/x-www-form-urlencoded— по параметру на строку,имя = значение, со снятым процентным кодированием.
event = ONCRMDEALUPDATE
event_handler_id = 975
data[FIELDS][ID] = 7445
ts = 1788948929
auth[domain] = demo.bitrix24.ru
auth[application_token] = stend_whsec_…
Ваш обработчик получает не это
Кнопка копирования рядом с заголовком панели кладёт в буфер сырое тело, а не разобранное. Именно оно приходит в обработчик, и именно от него считается подпись Wildberries. Разобранный вид — только для чтения глазами.
Если тело JSON, но разобрать его не удалось, панель покажет его как есть, не пытаясь приукрасить.
Повтор вручную
Кнопка «Повторить ошибочные» в подвале журнала берёт до 50 доставок в состояниях
failed и no_response, сбрасывает счётчик попыток и возвращает их в очередь.
Доставки Bitrix24 она пропускает намеренно: у боевого сервиса повторов нет, и мок не должен быть добрее — иначе стенд научит рассчитывать на то, чего в бою не будет. В ответе видно, сколько поставлено в очередь и сколько пропущено.
Что журнал не делает
- Не хранит ответ вашего приложения на виду: тело ответа пишется в базу (обрезанное до 4000 символов), но в интерфейсе показывается только код ответа и текст ошибки.
- Не фильтруется по состоянию и не ищется по идентификатору доставки: панель показывает последние 30 доставок песочницы, фильтры есть только у списка вебхуков выше.
- Не чистится по сроку. Ретеншен в 30 дней — про журнал запросов мок-шлюза, доставок он не касается. Уходят они вместе со своим вебхуком при его удалении или при сбросе демо-данных.