Подтверждённый заказ снова стал «новым», хотя сотрудник ничего не менял. Сначала нужно выяснить, что именно вернулось назад: запись в системе или только её отображение. Если запись перезаписало запоздалое уведомление, исправление должно учитывать актуальность события, а не только время его получения.
Начните с трёх безопасных действий:
- Откройте историю одного проблемного заказа штатным способом и отметьте переход назад: прежний статус, новый статус, время и автора изменения.
- Сравните состояние того же заказа на сайте и в системе, которая отвечает за этот этап: например, в CRM или кабинете доставки. Ничего не переотправляйте.
- Сохраните описание расхождения и время наблюдения с часовым поясом. Для передачи за пределы своей команды уберите контакты покупателя, состав заказа и другие закрытые сведения.
С 26 октября по 1 ноября команда OpenStart работала в том числе с интеграциями, серверной логикой и пользовательскими сценариями. В этом разборе остановимся на одной проверке таких связок: может ли старое сообщение отменить более новое состояние. Ниже — типовой учебный сценарий и критерии приёмки, а не описание исправления у конкретного клиента.
Как старое уведомление становится последней записью
Внешняя система может сообщать об изменении заказа отдельным запросом — вебхуком. Время события, время доставки уведомления и время его обработки на сайте не обязательно совпадают.
В учебном примере служба доставки сначала приняла отправление, затем передала его курьеру. Второе уведомление обработалось сразу, а первое пришло с задержкой. Если сайт каждый раз без проверки записывает полученный статус, карточка вернётся к «принято», хотя отправление уже у курьера.
Это возможный механизм, а не диагноз по одному экрану. Например, документация Stripe прямо предупреждает: доставка событий не гарантирована в порядке их возникновения. Но правила Stripe нельзя автоматически переносить на другую CRM или службу доставки — нужны условия именно вашего сервиса.
Отдельно различайте повтор одного события и разные события одного заказа. Защита от повторной обработки не остановит устаревшее сообщение с другим идентификатором. Если же проблема в создании второго заказа, пригодится отдельный разбор повторной отправки после таймаута.
Какие данные позволят проверить гипотезу
Попросите разработчика сопоставить историю изменения заказа с журналом входящих уведомлений. Достаточно небольшой выборки вокруг одного перехода назад; полная клиентская база для этого не нужна.
В закрытом рабочем протоколе полезны:
- условная метка заказа и связь с записью во внешней системе;
- идентификатор события и его тип, если сервис их предоставляет;
- время возникновения, получения и применения события — раздельно;
- версия состояния, если её смысл определён документацией источника;
- статус до обработки и после неё;
- обработчик или пользователь, выполнивший изменение.
По одному времени доставки нельзя определить, какое состояние новее. Даже время создания события не всегда даёт строгий порядок: Stripe, например, отмечает, что разные события могут иметь одинаковую временную метку. Версию состояния также нельзя путать с версией формата API — интерфейса обмена между системами.
Ответ «уведомление доставлено» подтверждает только этап доставки. Для проверки нужны сведения о том, было ли сообщение применено и почему обработчик выбрал такой результат.
Что ещё может объяснять возврат статуса
Сопоставление истории помогает отделить несколько гипотез.
Запоздалое событие. В журнале видно, что более старое состояние применилось после нового к той же записи. Подтверждением будет связь конкретного события с изменением карточки, а не просто близкое время двух записей.
Старое отображение. В основной системе статус актуален, но личный кабинет показывает прежний. Тогда проверяют обновление экрана или кеша — сохранённой копии ответа. Исправлять порядок уведомлений без такого различения преждевременно.
Другая автоматизация. Статус изменил робот CRM, обмен по расписанию или сотрудник. История должна показать этого участника; искать причину только в вебхуках недостаточно.
Смешение разных состояний. Статус оплаты, доставки и обработки заказа попал в одно поле. Успешная оплата не означает доставку, а возврат денег — возврат товара на склад. Нужна проверка соответствия полей и правил процесса.
Отмена, возврат или исправление ошибочно подтверждённого действия могут быть законными изменениями. Поэтому правило «всегда запрещать движение назад» способно сломать нормальную работу.
Как согласовать правило обработки
Для каждого поля определите систему, которая отвечает за его достоверность, и допустимые изменения. Правило должно отвечать на вопрос: почему конкретное уведомление можно применить к текущему состоянию?
Если источник предоставляет надёжную последовательность версий для одного объекта, разработчик может использовать её для проверки актуальности. Если такой гарантии нет, стоит рассмотреть получение текущего состояния через штатный интерфейс источника. Это разные варианты, выбор зависит от документации и устройства обмена.
Проверка и запись должны учитывать одновременную работу обработчиков. Иначе оба прочитают старое состояние и поздняя запись снова затрёт новое. Само наличие очереди этого не доказывает: важно поведение всей цепочки.
Для неопределённого результата нужен отдельный путь: сохранить сведения о событии, показать расхождение ответственному и выполнить согласованную сверку. Нельзя молча объявлять событие обработанным, если достоверное состояние определить не удалось.
Не запускайте массовую повторную доставку уведомлений и не меняйте статусы всех заказов ради проверки. Ошибочная обработка может затронуть уведомления покупателям, отгрузки и другие реальные действия. Воспроизведение поручают разработчику на изолированном тестовом контуре.
По каким сценариям принимать исправление
Согласуйте искусственный заказ и тестовые события, которые не запускают рабочую доставку, оплату или рассылку. Для каждого опыта заранее запишите ожидаемое состояние и допустимые побочные действия.
- Обычный порядок. Последовательные события приводят к согласованному итоговому статусу.
- Обратная доставка. Старое уведомление приходит после нового. Актуальное состояние сохраняется либо система выполняет предусмотренную сверку; причина решения видна в журнале.
- Повтор и одновременная обработка. Повторное событие не запускает лишнее действие, а конкурирующие обработчики не перезаписывают результат устаревшими данными.
- Законная отмена или возврат. Подтверждённое изменение проходит по правилам процесса и не блокируется общей защитой от «движения назад».
- Источник временно недоступен. Система сохраняет неопределённость для последующего разбора, не выдумывает статус и после восстановления связи сходится с подтверждёнными данными.
Результат проверки — протокол с исходным состоянием, порядком доставки, фактическим итогом и объяснением каждого решения обработчика. Скриншота исправленной карточки недостаточно.
Ранее затронутые заказы требуют отдельной сверки: новая версия кода сама по себе не исправляет уже записанные данные. Их восстановление согласуют отдельно, с учётом действий, которые успели выполнить сотрудники и внешние системы.
Когда достаточно своей команды
Владелец магазина может собрать историю одного расхождения и определить, какая система отвечает за каждый статус. Если разработчик знает правила обмена, располагает тестовой средой и может показать перечисленные проверки, задачу можно решить внутри команды.
Помощь уместна, когда старый модуль не документирован, один статус меняют несколько систем или ошибка связана с реальными отгрузками и её нельзя безопасно воспроизвести. В таком случае сначала ограничивают диагностику одним маршрутом и согласуют её результат.
OpenStart занимается исправлением ошибок и доработкой интеграций действующих сайтов. Объём работы и критерии приёмки уточняются до начала изменений.
Передайте описание сбоя на оценку доработки: укажите, какой статус вернулся назад и какие системы участвуют в обмене. Менеджер уточнит вводные, после чего можно согласовать первый этап. Пароли, токены и выгрузка заказов для первого обращения не нужны.