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.
