Обновления заказа пришли не по порядку: какие правила согласовать заранее

Подготовлено 23 октября 2026 года

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

Покажите один учебный конфликт

Учебный заказ У-43 сначала переведён партнёром в состояние «Обработка начата», затем — «Передан на следующий этап». Второе сообщение магазин получил раньше первого. Если безусловно показывать последнее полученное значение, более раннее событие вернёт заказ назад. Эти названия придуманы и не описывают конкретного перевозчика.

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

Согласуйте источник порядка

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

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

Опишите допустимые переходы

Отдельно перечислите переходы, которые требуют нового бизнес-основания. Возврат на предыдущую стадию может быть допустимым изменением, а не старым событием. Поэтому простая таблица «статус выше — всегда правильнее» также требует проверки на реальные сценарии.

Не теряйте свидетельство спорного события

Для разбора полезны номера заказа и сообщения, оба времени с часовыми поясами, доступный признак версии, полученное значение и принятое решение. В истории У-43 должна остаться причина, почему сообщение версии 7 не изменило экран после версии 8.

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

Проверьте повтор и противоречие

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

Четвёртый пример — разные значения без проверяемого порядка. Ожидаемый результат здесь не придуманное «последнее верное», а открытый конфликт с ответственным. В отличие от опоздавших данных отчётного периода, вопрос относится к текущему решению по одному живому заказу.

Как поставить задачу адаптеру

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

Заказ и источник событий:
Признак порядка / документированное значение:
Время события / время получения:
Допустимые переходы и исключения:
Ожидаемое состояние при обратном порядке:
Повтор сообщения — ожидаемое поведение:
Конфликт без надёжного порядка — ответственный:
Запись для разбора / срок и доступ:
Контрольные примеры и свидетельство решения:

Если такой участок есть в вашем проекте, опишите одно действие и нужный результат. Первый разговор бесплатный; готовое ТЗ не обязательно. Обсудить свою задачу.