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

Это проектный пример, не рассказ о сбое конкретной площадки. Возможность нескольких посылок и сроков внутри одного заказа описана, например, в справке Яндекс Маркета. Вопрос здесь не к Маркету, а к любому сервису, который вводит подобное поведение: что означает «откатили», если покупатель уже получил два отдельных обещания о доставке?

Старый экран знает одну дату заказа. Но какую дату ему показать? Пятницу — и создать впечатление, будто готово всё? Понедельник — и скрыть первую посылку? То же со статусом: «Готов к выдаче» верно для одной части и неверно для другой. Дело не в том, как назвать поле в API. Однозначного старого значения больше нет.

Флаг может остановить создание новых разделённых заказов. Однако чтение и обслуживание уже созданных должно продолжаться. Это две разные способности системы, даже если управление ими выглядит как одна кнопка. Возврат прежней версии сервера — третий шаг: перед ним надо доказать, что старый код понимает новые записи. Исправление неверно записанных сроков — четвёртый, уже ручной или специально разработанный процесс, а не действие флага.

С мобильным приложением сложнее: старая сборка может оставаться у покупателя месяцами. Заказ, оформленный на новом телефоне, он откроет на старом планшете. Если прежняя версия умеет показывать только одну дату, сервер не должен подменять правду «приблизительным» общим сроком. Надо заранее подготовить честное упрощённое представление, поддерживаемый веб-экран или правило обновления клиента. После запуска функции научить старый бинарный файл новому смыслу уже нельзя.

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

Перед запуском этой функции полезно провести простую проверку: старый и новый клиент × обычный и разделённый заказ × функция включена и выключена. Не на пустой базе: сначала создать разделённый заказ, потом выключить оформление и пройти путь покупателя до конца. Это критерий для будущего тестирования, а не результат уже проведённого эксперимента.

И ещё до запуска стоит определить условие остановки вместе с бизнесом. Одно дело — временно убрать выбор доставки для новых покупок. Другое — менять уже подтверждённый срок или лишать покупателя возможности перенести существующую посылку. Кто решает, допустим ли такой обход? Сколько он может действовать? Кто объяснит изменение поддержке и самим покупателям? Без этих ответов инженер с доступом к флагу фактически принимает продуктовое решение в одиночку.

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

Полный инженерный разбор — ArkTelos Lab. Об экосистеме — ArkTelos. Каналы лаборатории: RU | EN.