Michael JohnsonNach einem Deployment kann ein aktives Cloudflare Durable Object jetzt mit der aktuellen Codeversion weiterlaufen, bis es in den Ruhezustand wechselt oder die festgelegte Frist abläuft. Am 30. Oktober legte Cloudflare verzögerte Updates als Standard fest, mit einer maximalen Verzögerung von fünf Minuten. Für Entwickler ändert sich damit das Verhalten bereits laufender Objekte während eines Rollouts: Ein Update muss sie nicht sofort unterbrechen, und unterstützte WebSocket-Verbindungen können beim Wechsel auf eine neue Version erhalten bleiben.
Was während eines Deployments geschieht
Durable Objects sind adressierbare Objekte mit dauerhafter Identität und dauerhaftem Zustand, die Cloudflare unter anderem zur Koordination von Clients, für lang laufende Aufgaben und für WebSocket-Sitzungen verwendet. Für ein Objekt ist jeweils nur eine Codeversion aktiv. Bei einem sofortigen Austausch kann die aktive Instanz deshalb zurückgesetzt werden und laufende Arbeit oder Verbindungen unterbrechen.
Das Standardverhalten ist jetzt ein verzögerter Wechsel. Nach dem Rollout verarbeitet das aktive Objekt Anfragen weiterhin mit der alten Version. Wechselt es vorher in den Ruhezustand, wird beim nächsten Zugriff die neue Version gestartet. Sind fünf Minuten verstrichen und das Objekt ist noch aktiv, wird es zurückgesetzt und übernimmt die neue Version. Das Deployment des Workers wird davon unabhängig abgeschlossen: Die Verzögerung betrifft den Zeitpunkt, zu dem ein bereits aktives Objekt den neuen Code ausführt.
Für wen das nützlich ist
Die Änderung ist wichtig für Dienste, bei denen ein einzelnes Objekt Arbeit zwischen Anfragen aufrechterhält, etwa eine lange Sitzung, die Koordination mehrerer Clients oder eine WebSocket-Verbindung. Der verzögerte Wechsel schafft ein Zeitfenster, in dem ein solches Objekt seine aktuelle Arbeit auf natürliche Weise beenden oder in den Ruhezustand wechseln kann, bevor es aktualisiert wird. Für WebSocket-Verbindungen nennt Cloudflare eine besondere Voraussetzung: Verbindungen, die die Hibernation API verwenden, bleiben bestehen, wenn das Objekt nach dem Wechsel in den Ruhezustand den neuen Code übernimmt.
Für Teams bedeutet das konkret: Sie sollten ermitteln, welche aktiven Objekte länger als einige Minuten beschäftigt sein können, und prüfen, welche WebSocket-API zum Einsatz kommt. Davon hängt ab, ob das neue Deployment-Verhalten der Anwendung einen sanften Übergang ermöglicht oder ob die Verbindung beim erzwungenen Update beendet wird.
Fünf Minuten sind ein Zeitfenster, keine Garantie
Cloudflare beschreibt das verzögerte Update als Best-Effort-Verfahren: Ein Objekt kann früher zurückgesetzt werden, etwa bei einer Aktualisierung der Laufzeitumgebung. Wechselt es bis zum Ende der maximalen Verzögerung nicht in den Ruhezustand, setzt die Plattform die neue Version durch einen Reset durch. Wichtige Zustände sollten daher dauerhaft gespeichert und Operationen so gestaltet werden, dass sie erneut ausgeführt werden können. Die Cloudflare-Dokumentation empfiehlt, Zustände zu speichern, die Deployments überstehen müssen, statt sich auf den Arbeitsspeicher der aktiven Instanz zu verlassen.
Teams können das Verhalten in der Konfiguration von Durable Objects überschreiben: Sie können sofortige Updates festlegen oder für den verzögerten Wechsel eine andere Frist wählen. Der Sofortmodus ist sinnvoll, wenn eine neue Version unmittelbar aktiv werden muss, etwa bei einem dringenden Fix. Eine längere Verzögerung kann Objekten mehr Zeit geben, verlängert aber auch den Zeitraum, in dem ein Teil der Instanzen noch die alte Version verwendet.
Was vor dem nächsten Rollout zu prüfen ist
Prüfen Sie die Kompatibilität der Anfragen zwischen Worker und Durable Object für den Zeitraum, in dem beide mit unterschiedlichen Versionen laufen können. Stellen Sie sicher, dass kritische Zustände im Speicher und nicht nur im Arbeitsspeicher gesichert werden. Prüfen Sie bei WebSocket-Verbindungen, ob die Anwendung die Hibernation API verwendet: Gewöhnliche Verbindungen können beim Anwenden des Updates beendet werden. Wenn das Deployment einen sofortigen Wechsel erfordert, kontrollieren Sie die ausdrückliche Einstellung des Modus, statt sich auf den neuen Standardwert zu verlassen.
Cloudflare hat damit den üblichen Kompromiss beim Deployment verändert: Aktive Objekte erhalten eine begrenzte Zeit für einen natürlichen Übergang, während Teams das Update weiterhin per Einstellung beschleunigen können. Für Entwickler ist es am hilfreichsten, vor dem nächsten Rollout die Kompatibilität alter und neuer Versionen, die dauerhafte Speicherung des Zustands und den verwendeten WebSocket-Typ zu prüfen.
