Порядок событий и защита статуса от отката
Версия 2.7
Храните получение и результат отдельно
Обработчик может принять несколько событий для одного отправления через разные реплики. В локальной модели храните время получения, идентификатор события и итог его применения раздельно. Два события с разными event_id представляют разные сообщения, даже если относятся к одному отправлению. Два появления одного event_id указывают на повтор доставки того же сообщения.
Доставка после более нового события
Порядок поступления в очередь сам по себе не определяет порядок состояний отправления. Если новое для обработчика уведомление противоречит уже показанному статусу, сравните его с текущим статусом в кабинете RouteDesk. Подтвердите последнюю запись по истории отправления, затем обновите локальное состояние. Избегайте автоматической замены статуса только потому, что запись пришла позже.
Когда порядок надо проверить вручную
Отметьте конфликт, если уведомление содержит состояние, несовместимое с текущим этапом заказа, или если связь между локальным заказом и номером RouteDesk не подтверждена. Покажите оператору время событий, подтверждённый статус и необработанную задачу. Для разбора достаточно идентификаторов и истории статусов. Данные получателя не помогают определить последовательность.
Что не следует считать переходом
Повтор сообщения с тем же event_id не создаёт нового перехода. Регистрация этикетки сама по себе не подтверждает сдачу перевозчику. В RouteDesk первый скан переводит отправление из «Создано» в «Принято». Если магазин формирует собственное уведомление клиенту, привяжите его к подтверждённому изменению, чтобы поздний повтор не отправил повторное письмо или неверный статус.
Проверка на порядке, отличном от ожидаемого
В тестовом контуре дайте обработчику два разных сообщения в обратной последовательности и одно из них повторите. Проверьте, что сырые события учтены, событие с одинаковым event_id обработано один раз, а итоговый статус совпал с подтверждённой историей. Для случаев с неоднозначным переходом проверьте, что дежурный получает задание на сверку с нужными идентификаторами.
Как пересчитать локальное представление
При разборе конфликтов сохраняйте исходные события и текущий номер RouteDesk. Сначала сформируйте ожидаемое состояние по подтверждённой истории, затем проверьте, что обновляется именно связанный заказ. Для пересчёта можно использовать отдельную локальную операцию. Отметьте источник подтверждения и время, чтобы следующее входящее событие не отменило исправление без проверки.
Что записать в историю
Для каждого расхождения сохраните прежнее состояние, проверенный статус и решение об отложенном событии. Отметьте, был ли клиент уведомлён до исправления, чтобы не послать ему повторное сообщение. При последующей сверке оператор должен суметь восстановить причину обновления по идентификаторам, даже если события в рабочей очереди уже обработаны.