Кейс

Дубли заказов при интеграции с маркетплейсом

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

Суть спора

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

Повторная доставка уведомления может быть штатным поведением интеграции. Нужно проверить контракт обмена и способность обработчика безопасно принять одно событие несколько раз.

Объект исследования

Спецификация обмена и согласованная версия API

Версия модуля интеграции и его настройки

Журналы запросов, ответов и очереди сообщений

Карточки заказов, резервы и история остатков

Вопросы эксперту

На каком этапе возникает повторная запись?

Обрабатываются ли повторы с одним идентификатором события?

Чем вызвана задержка синхронизации остатков?

Воспроизводится ли ошибка на переданной версии модуля?

Методики и инструменты

Сопоставление событий по идентификаторам заказа и запроса
Контрольное повторение уведомлений в тестовой среде
Проверка тайм-аутов, очереди и обработки ошибок
Сравнение результата с согласованным контрактом обмена

Ход исследования

Этап 1 · Сбор цепочки · Объединяют журналы участников, сохраняя исходные временные метки и идентификаторы.

Этап 2 · Повтор уведомления · На тестовой копии передают одно событие повторно и проверяют число созданных резервов.

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

Этап 4 · Описание дефекта · Фиксируют условия воспроизведения, версию модуля и ожидаемый результат по спецификации.

Результаты исследования

Повторная доставка

В ходе исследования внешняя система повторяет уведомление после тайм-аута ответа.

Двойной резерв

Модуль создаёт новый резерв вместо распознавания уже обработанного события.

Очередь растёт

Повторные ошибки блокируют последующие обновления остатков на исследуемой конфигурации.

Область вывода

Дефект подтверждён для зафиксированной версии; состояние всех интеграций магазина этим тестом не определяется.

Выводы и практическая польза

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

Что даёт такое исследование

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

Материалы для первичной оценки

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