Michael JohnsonПосле деплоя активный Cloudflare Durable Object теперь может продолжить работу на текущей версии кода, пока не перейдёт в гибернацию, либо до истечения установленного срока. 30 октября Cloudflare установила отложенное обновление по умолчанию с максимальной задержкой пять минут. Для разработчиков это меняет поведение уже работающих объектов во время выкладки: обновление не обязано немедленно прерывать их, а поддерживаемые WebSocket-соединения могут сохраниться при переходе на новую версию.
Что происходит во время деплоя
Durable Objects — адресуемые объекты с устойчивой идентичностью и состоянием, которые Cloudflare использует, в частности, для координации клиентов, длительных задач и WebSocket-сессий. Для одного объекта одновременно действует одна версия кода. Поэтому при немедленной замене активный экземпляр может сброситься, прервав работу или соединения.
Теперь стандартный сценарий — отложенный переход. После выкладки активный объект продолжает обслуживать запросы на старой версии. Если он успевает перейти в гибернацию раньше, новая версия будет запущена при следующем обращении. Если пять минут истекли, а объект всё ещё активен, он сбрасывается и принимает новую версию. Развёртывание Worker при этом завершается отдельно: задержка касается момента, когда уже активный объект начнёт исполнять новый код.
Кому это полезно
Изменение важно для сервисов, где один объект удерживает работу между запросами: например, для долгой сессии, координации нескольких клиентов или соединения WebSocket. Отложенный переход создаёт окно, в котором такой объект может естественно завершить текущую активность или уснуть, прежде чем обновиться. Для WebSocket Cloudflare отдельно указывает условие: соединения, использующие Hibernation API, остаются подключёнными, когда объект принимает новый код после гибернации.
Практический вывод для команды — определить, какие активные объекты могут оставаться занятыми дольше нескольких минут, и выяснить, какой API WebSocket используется. От этого зависит, даст ли новый порядок деплоя приложению шанс на мягкий переход или соединение завершится при принудительном обновлении.
Пять минут — окно, а не гарантия
Cloudflare описывает отложенное обновление как best effort: объект может сброситься раньше, например при обновлении среды выполнения. Если он не ушёл в гибернацию к концу максимальной задержки, платформа применит новую версию через сброс. Поэтому важное состояние следует сохранять в долговременном хранилище, а операции проектировать с учётом возможного повторного запуска. Документация Cloudflare рекомендует сохранять состояние, которое должно переживать деплои, а не рассчитывать на память активного экземпляра.
Команды могут переопределить поведение в конфигурации Durable Objects: задать режим немедленного обновления либо выбрать другой срок для отложенного перехода. Немедленный режим пригодится, когда новая версия должна вступить в действие сразу, например при срочном исправлении; более длинная задержка может дать объектам дополнительное время, но также продлевает период, когда часть экземпляров обслуживает старую версию.
Что проверить перед следующей выкладкой
Сверьте совместимость запросов между Worker и Durable Object на время, когда они могут работать на разных версиях. Проверьте, сохраняется ли критическое состояние в хранилище, а не только в памяти. Для WebSocket установите, использует ли приложение Hibernation API: обычные соединения могут завершиться при применении обновления. Если деплой требует немедленного перехода, проверьте явную настройку режима, вместо того чтобы полагаться на новое значение по умолчанию.
Таким образом, Cloudflare изменила стандартный компромисс при деплое: активные объекты получают ограниченное время для естественного перехода, а команды сохраняют возможность ускорить обновление настройкой. Самый полезный результат для разработчика — проверить совместимость старой и новой версий, сохранность состояния и тип WebSocket до следующей выкладки.
