Michael JohnsonNa een deployment kan een actief Cloudflare Durable Object nu op de huidige codeversie blijven draaien totdat het in slaapstand gaat, of totdat de ingestelde termijn verstrijkt. Op 30 oktober stelde Cloudflare uitgestelde updates standaard in, met een maximale vertraging van vijf minuten. Voor ontwikkelaars verandert dit hoe bestaande objecten zich tijdens een uitrol gedragen: een update hoeft ze niet onmiddellijk te onderbreken, en ondersteunde WebSocket-verbindingen kunnen behouden blijven wanneer ze naar een nieuwe versie overgaan.
Wat er tijdens een deployment gebeurt
Durable Objects zijn adresseerbare objecten met een blijvende identiteit en status. Cloudflare gebruikt ze onder meer voor de coördinatie van clients, langdurige taken en WebSocket-sessies. Voor één object is er steeds maar één codeversie actief. Bij een onmiddellijke vervanging kan de actieve instantie daarom worden gereset, waardoor werk of verbindingen worden onderbroken.
De standaardprocedure is nu een uitgestelde overgang. Na de uitrol blijft een actief object verzoeken afhandelen met de oude versie. Gaat het eerder in slaapstand, dan wordt de nieuwe versie gestart bij het volgende verzoek. Als de vijf minuten zijn verstreken en het object nog steeds actief is, wordt het gereset en neemt het de nieuwe versie over. De deployment van de Worker wordt apart afgerond: de vertraging betreft het moment waarop een al actief object nieuwe code begint uit te voeren.
Voor wie dit nuttig is
De verandering is van belang voor diensten waarbij één object actief blijft tussen verzoeken, bijvoorbeeld tijdens een lange sessie, de coördinatie van meerdere clients of een WebSocket-verbinding. Door de uitgestelde overgang krijgt zo'n object de gelegenheid om de huidige activiteit op natuurlijke wijze af te ronden of in slaapstand te gaan voordat het wordt bijgewerkt. Voor WebSockets noemt Cloudflare een specifieke voorwaarde: verbindingen die de Hibernation API gebruiken, blijven actief wanneer het object na de slaapstand nieuwe code overneemt.
De praktische conclusie voor teams is dat ze moeten bepalen welke actieve objecten langer dan enkele minuten bezig kunnen blijven en moeten nagaan welke WebSocket-API ze gebruiken. Dat bepaalt of de nieuwe deploymentvolgorde de toepassing een kans op een soepele overgang biedt, of dat de verbinding bij een gedwongen update wordt beëindigd.
Vijf minuten is een tijdvenster, geen garantie
Cloudflare omschrijft uitgestelde updates als best effort: een object kan eerder worden gereset, bijvoorbeeld bij een update van de runtime-omgeving. Als het aan het einde van de maximale vertraging niet in slaapstand is gegaan, past het platform de nieuwe versie toe door het object te resetten. Sla belangrijke status daarom op in permanente opslag en ontwerp bewerkingen zo dat ze opnieuw kunnen worden uitgevoerd. De documentatie van Cloudflare raadt aan status op te slaan die deployments moet overleven, in plaats van te vertrouwen op het geheugen van de actieve instantie.
Teams kunnen het gedrag aanpassen in de configuratie van Durable Objects: ze kunnen kiezen voor onmiddellijke updates of een andere termijn instellen voor de uitgestelde overgang. De onmiddellijke modus is handig wanneer een nieuwe versie meteen actief moet worden, bijvoorbeeld bij een spoedreparatie. Een langere vertraging kan objecten extra tijd geven, maar verlengt ook de periode waarin sommige instanties de oude versie gebruiken.
Wat je vóór de volgende uitrol moet controleren
Controleer of verzoeken compatibel blijven tussen de Worker en Durable Object terwijl ze mogelijk op verschillende versies draaien. Ga na of kritieke status in opslag wordt bewaard en niet alleen in het geheugen. Controleer voor WebSockets of de toepassing de Hibernation API gebruikt: gewone verbindingen kunnen worden beëindigd wanneer de update wordt toegepast. Als de deployment onmiddellijk moet overgaan, controleer dan de expliciete instelling voor de modus in plaats van te vertrouwen op de nieuwe standaardwaarde.
Cloudflare heeft daarmee de standaardafweging bij deployments veranderd: actieve objecten krijgen een beperkte tijd om op natuurlijke wijze over te gaan, terwijl teams de update via een instelling kunnen versnellen. Het nuttigste voor ontwikkelaars is om vóór de volgende uitrol de compatibiliteit van de oude en nieuwe versies, het behoud van status en het type WebSocket te controleren.
