Michael JohnsonPo wdrożeniu aktywny Cloudflare Durable Object może teraz kontynuować działanie na bieżącej wersji kodu, dopóki nie przejdzie w stan hibernacji albo nie upłynie wyznaczony czas. 30 października Cloudflare domyślnie włączyła opóźnione aktualizacje z maksymalnym opóźnieniem wynoszącym pięć minut. Dla programistów zmienia to zachowanie już działających obiektów podczas wdrażania: aktualizacja nie musi natychmiast ich przerywać, a obsługiwane połączenia WebSocket mogą zostać zachowane podczas przejścia na nową wersję.
Co dzieje się podczas wdrożenia
Durable Objects to adresowalne obiekty o trwałej tożsamości i stanie, których Cloudflare używa między innymi do koordynowania klientów, obsługi długotrwałych zadań i sesji WebSocket. Dla jednego obiektu jednocześnie działa jedna wersja kodu. Dlatego natychmiastowa podmiana może zresetować aktywną instancję, przerywając jej pracę lub połączenia.
Teraz standardowym scenariuszem jest odroczone przejście. Po wdrożeniu aktywny obiekt nadal obsługuje żądania przy użyciu starej wersji. Jeśli wcześniej przejdzie w stan hibernacji, nowa wersja zostanie uruchomiona przy następnym żądaniu. Jeśli minie pięć minut, a obiekt nadal będzie aktywny, zostanie zresetowany i zacznie używać nowej wersji. Wdrożenie Workera kończy się niezależnie: opóźnienie dotyczy momentu, w którym już aktywny obiekt zacznie wykonywać nowy kod.
Komu to się przyda
Zmiana ma znaczenie dla usług, w których jeden obiekt podtrzymuje działanie między żądaniami, na przykład długiej sesji, koordynacji wielu klientów lub połączenia WebSocket. Odroczone przejście tworzy okno, w którym taki obiekt może naturalnie zakończyć bieżącą aktywność albo przejść w stan uśpienia przed aktualizacją. W przypadku WebSocket Cloudflare wskazuje osobny warunek: połączenia korzystające z Hibernation API pozostają aktywne, gdy obiekt przyjmuje nowy kod po hibernacji.
Praktyczny wniosek dla zespołu jest taki, by ustalić, które aktywne obiekty mogą pozostawać zajęte przez ponad kilka minut, oraz sprawdzić, z którego API WebSocket korzysta aplikacja. Od tego zależy, czy nowy sposób wdrażania da aplikacji szansę na łagodne przejście, czy też połączenie zakończy się podczas wymuszonej aktualizacji.
Pięć minut to okno, a nie gwarancja
Cloudflare opisuje opóźnioną aktualizację jako rozwiązanie typu best effort: obiekt może zostać zresetowany wcześniej, na przykład podczas aktualizacji środowiska wykonawczego. Jeśli do końca maksymalnego czasu opóźnienia nie przejdzie w stan hibernacji, platforma zastosuje nową wersję przez reset. Dlatego ważny stan należy zapisywać w trwałym magazynie, a operacje projektować z uwzględnieniem możliwości ponownego uruchomienia. Dokumentacja Cloudflare zaleca zapisywanie stanu, który ma przetrwać wdrożenia, zamiast polegania na pamięci aktywnej instancji.
Zespoły mogą zmienić to zachowanie w konfiguracji Durable Objects: ustawić tryb natychmiastowej aktualizacji albo wybrać inny czas odroczonego przejścia. Tryb natychmiastowy przyda się, gdy nowa wersja musi wejść w życie od razu, na przykład w przypadku pilnej poprawki; dłuższe opóźnienie może dać obiektom więcej czasu, ale również wydłuża okres, w którym część instancji obsługuje starą wersję.
Co sprawdzić przed kolejnym wdrożeniem
Sprawdź zgodność żądań między Workerem a Durable Object w okresie, gdy mogą działać na różnych wersjach. Upewnij się, że krytyczny stan jest zapisywany w magazynie, a nie tylko w pamięci. W przypadku WebSocket sprawdź, czy aplikacja korzysta z Hibernation API: zwykłe połączenia mogą zostać zakończone podczas stosowania aktualizacji. Jeśli wdrożenie wymaga natychmiastowego przejścia, sprawdź jawne ustawienie trybu zamiast polegać na nowej wartości domyślnej.
Cloudflare zmieniła więc domyślny kompromis związany z wdrożeniami: aktywne obiekty otrzymują ograniczony czas na naturalne przejście, a zespoły nadal mogą przyspieszyć aktualizację za pomocą ustawień. Najbardziej przydatny wniosek dla programisty to sprawdzenie zgodności starej i nowej wersji, trwałości stanu oraz rodzaju połączenia WebSocket przed kolejnym wdrożeniem.
