Shopify Functions: код готов, а обновление магазина заблокировано

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

У владельца возникает вполне обоснованный вопрос: если мы оплатили разработку и код уже готов, почему нельзя просто включить изменение? Следом появляется сомнение в качестве работы подрядчика. Я понимаю эту реакцию. Однако прежде чем обсуждать ответственность и сроки, нужно установить, на каком этапе остановилось обновление и что происходит с магазином прямо сейчас.

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

Что показало обсуждение разработчиков

2 октября 2026 года в Shopify Developer Community появились сообщения о блокировке изменений WebAssembly-модулей Functions. Участники описывали ошибки при shopify app dev и shopify app deploy. Представитель Shopify подтвердил временную приостановку, а позднее в тот же день сообщил о возможности продолжить развёртывание. 5 октября другой участник снова сообщил о той же ошибке при app dev. На дату проверки, 6 октября, в ветке нет следующего ответа Shopify, объясняющего этот случай. [1]

Это не основание утверждать, что все приложения Shopify по-прежнему заблокированы. Причина последнего сообщения не установлена. Для конкретного проекта нужны собственные проверки; форум помогает увидеть возможную внешнюю зависимость, но не заменяет диагностику.

Я вижу в этой ситуации более широкий вопрос: как построена работа с приложением, если срочное исправление нельзя выпустить в момент, когда оно нужно магазину?

Сначала проверяем продажи, затем выпуск обновления

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

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

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

Когда источник сбоя ещё неясен, диагностика Shopify-магазина помогает связать технические симптомы с конкретными действиями покупателя. Без этой связи легко потратить время на запуск команды и упустить неверную сумму в реальном заказе.

Где проходит граница между приложением и Shopify

Shopify Functions выполняются внутри серверной логики Shopify: платформа вызывает скомпилированный WebAssembly-модуль в нужной точке покупательского сценария. Это важное отличие от серверной части приложения, которую разработчик размещает на собственном хостинге. [2]

Команда shopify app deploy собирает приложение и отправляет в Shopify его конфигурацию и расширения. По умолчанию она создаёт и выпускает версию; параметр --no-release позволяет создать её без выпуска для магазинов. Эта команда не размещает веб-приложение на собственном сервере. [3]

Поэтому предложение «перенесём приложение на другой VPS» нужно оценивать по месту отказа. Если проблема возникла на нашем сервере, перенос иногда имеет смысл. Если Shopify не принимает новый модуль Function, смена хостинга сама по себе не открывает этот путь. Она может добавить работу, расходы и ещё одну неопределённость.

В разработке приложений Shopify я считаю необходимым заранее объяснять владельцу, какие части решения мы размещаем и обновляем самостоятельно, а какие принимаются и исполняются платформой. Это влияет на сроки, поддержку и возможность срочного вмешательства.

Почему «мы ничего не меняли» ещё не объясняет ошибку

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

Я начинаю с сохранения исходных данных: точного текста ошибки, времени с часовым поясом, команды, версии CLI, выбранного приложения и магазина, версии API, идентификатора исходного кода и последнего успешного выпуска. Затем отдельно проверяю сборку и попытку передачи результата в Shopify. Для обращения в поддержку готовлю минимальное воспроизведение без секретов и персональных данных.

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

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

Как продолжать работу, пока платформа не принимает обновление

Команда app dev тоже взаимодействует с Shopify: при изменениях Function CLI обновляет её черновик для проверки на тестовом магазине. Для отдельной локальной проверки логики Shopify предлагает app function run с входными данными JSON и app function replay для сохранённого выполнения. Также доступны модульные тесты и проверки скомпилированного WebAssembly. [4]

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

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

Когда доступ к проверке на Shopify восстановится, нужно пройти соответствующий покупательский сценарий целиком. Успешная загрузка файла завершает только этап доставки изменения. Приёмка требует правильного результата для покупателя.

Почему опасно удалять Function ради успешного выпуска

Убирая расширение из проекта и выпуская новую версию, разработчик меняет состав приложения, доступный магазинам. Это не просто локальная настройка. [5] Для Functions Shopify отдельно предупреждает: удаление приводит к постоянному удалению функции и связанных с ней объектов-владельцев — например, настроенного правила скидки. [2]

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

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

Возврат к предыдущей версии нужно готовить заранее

Shopify позволяет выпустить ранее созданную версию приложения. При этом версия объединяет конфигурацию и расширения, а размещённое отдельно веб-приложение не откатывается автоматически. [6]

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

Я бы требовал от проекта понятного описания: какая версия сейчас работает, какой результат проверен, к чему можно вернуться и какие данные при этом сохраняются. Блокировка нового развёртывания не гарантирует доступность любого другого действия в Shopify. Возможность конкретного восстановления проверяется отдельно.

Ещё на этапе выбора решения необходимо проверить тариф магазина, способ распространения приложения и нужный Function API. Публичные приложения с Functions доступны на любых тарифах; для custom apps с Functions требуется Shopify Plus, а отдельные возможности имеют дополнительные ограничения. [2] Индивидуальная разработка как услуга и custom app как модель Shopify — разные понятия. Их смешение может привести к обещанию функции, которую выбранным способом нельзя предоставить магазину.

Этот вопрос важен и при разработке расширений Shopify: сначала проверяется допустимая архитектура, затем оцениваются реализация и сроки.

Что владелец должен получить от команды

Фраза «ждём Shopify» объясняет зависимость, но оставляет владельца без основы для решения. Я ожидаю от команды конкретного сообщения: что подтверждено, что работает сейчас, какие продажи или процессы затронуты, какое действие возможно и когда будет следующая проверка статуса. Обещать срок восстановления чужой платформы без подтверждения нельзя.

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

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

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