Michael JohnsonEfter en driftsättning kan ett aktivt Cloudflare Durable Object nu fortsätta köras med den aktuella kodversionen tills det går i viloläge eller den angivna tidsgränsen löper ut. Den 30 oktober införde Cloudflare uppskjutna uppdateringar som standard, med en maximal fördröjning på fem minuter. För utvecklare ändrar detta hur redan aktiva objekt beter sig under en driftsättning: uppdateringen behöver inte avbryta dem omedelbart, och WebSocket-anslutningar som stöds kan bevaras när objektet övergår till den nya versionen.
Vad händer under en driftsättning?
Durable Objects är adresserbara objekt med beständig identitet och beständigt tillstånd, som Cloudflare bland annat använder för att samordna klienter, hantera långvariga uppgifter och upprätthålla WebSocket-sessioner. Ett objekt kör bara en kodversion åt gången. Därför kan en omedelbar ersättning återställa den aktiva instansen och avbryta arbete eller anslutningar.
Det normala förloppet är nu en uppskjuten övergång. Efter driftsättningen fortsätter det aktiva objektet att hantera förfrågningar med den gamla versionen. Om det hinner gå i viloläge först startar den nya versionen vid nästa förfrågan. Om fem minuter har gått och objektet fortfarande är aktivt återställs det och börjar använda den nya versionen. Driftsättningen av Worker slutförs separat: fördröjningen gäller när ett redan aktivt objekt börjar köra den nya koden.
Vem har nytta av förändringen?
Förändringen är viktig för tjänster där ett objekt upprätthåller arbete mellan förfrågningar, till exempel en lång session, samordning av flera klienter eller en WebSocket-anslutning. Den uppskjutna övergången skapar ett tidsfönster då objektet kan avsluta sin pågående aktivitet på ett naturligt sätt eller gå i viloläge innan det uppdateras. För WebSocket anger Cloudflare ett särskilt villkor: anslutningar som använder Hibernation API förblir anslutna när objektet tar emot ny kod efter att ha gått i viloläge.
Den praktiska slutsatsen för teamet är att avgöra vilka aktiva objekt som kan förbli upptagna längre än några minuter och ta reda på vilket WebSocket-API som används. Det avgör om den nya driftsättningsordningen ger appen möjlighet till en mjuk övergång eller om anslutningen avslutas vid en tvingad uppdatering.
Fem minuter är ett tidsfönster, inte en garanti
Cloudflare beskriver uppskjutna uppdateringar som best effort: objektet kan återställas tidigare, till exempel vid en uppdatering av körmiljön. Om det inte har gått i viloläge när den maximala fördröjningen löper ut tillämpar plattformen den nya versionen genom en återställning. Därför bör viktigt tillstånd sparas i beständig lagring, och åtgärder utformas med hänsyn till att de kan behöva köras igen. Cloudflares dokumentation rekommenderar att tillstånd som ska överleva driftsättningar sparas, i stället för att förlita sig på den aktiva instansens minne.
Team kan åsidosätta beteendet i Durable Objects-konfigurationen: välja omedelbar uppdatering eller ange en annan tidsgräns för den uppskjutna övergången. Omedelbart läge kan vara lämpligt när den nya versionen måste börja gälla direkt, till exempel vid en brådskande korrigering. En längre fördröjning kan ge objekten mer tid, men förlänger också perioden då vissa instanser kör den gamla versionen.
Det här bör du kontrollera före nästa driftsättning
Kontrollera att förfrågningar är kompatibla mellan Worker och Durable Object under tiden då de kan köras med olika versioner. Se till att kritiskt tillstånd sparas i lagring och inte bara i minnet. För WebSocket bör du kontrollera om appen använder Hibernation API: vanliga anslutningar kan avslutas när uppdateringen tillämpas. Om driftsättningen kräver en omedelbar övergång bör du kontrollera att läget är uttryckligen konfigurerat i stället för att förlita dig på det nya standardvärdet.
Cloudflare har alltså ändrat standardavvägningen vid driftsättning: aktiva objekt får en begränsad tid för en naturlig övergång, samtidigt som teamen kan påskynda uppdateringen genom en inställning. Det viktigaste för utvecklare är att kontrollera kompatibiliteten mellan den gamla och den nya versionen, att tillståndet bevaras och vilken typ av WebSocket som används före nästa driftsättning.
