Cloudflare utsetter oppdateringer av Durable Objects slik at aktive oppgaver kan fullføres

Etter en utrulling kan et aktivt Cloudflare Durable Object nå fortsette å kjøre den gjeldende kodeversjonen til det går i dvale, eller til den angitte tidsfristen utløper. 30. oktober innførte Cloudflare utsatt oppdatering som standard, med en maksimal forsinkelse på fem minutter. For utviklere endrer dette hvordan objekter som allerede kjører, håndteres under utrulling: Oppdateringen trenger ikke å avbryte dem umiddelbart, og WebSocket-forbindelser som støttes, kan bevares når de går over til den nye versjonen.

Hva skjer under en utrulling?

Durable Objects er adresserbare objekter med en stabil identitet og tilstand, som Cloudflare blant annet bruker til å koordinere klienter, håndtere langvarige oppgaver og administrere WebSocket-økter. Hvert objekt kjører én kodeversjon om gangen. Hvis den erstattes umiddelbart, kan den aktive instansen derfor bli tilbakestilt, slik at arbeid eller forbindelser avbrytes.

Standardforløpet er nå en utsatt overgang. Etter utrullingen fortsetter det aktive objektet å behandle forespørsler med den gamle versjonen. Hvis det går i dvale først, starter den nye versjonen ved neste forespørsel. Hvis fem minutter går uten at objektet har gått i dvale, tilbakestilles det og tar i bruk den nye versjonen. Utrullingen av Worker fullføres separat: Forsinkelsen gjelder tidspunktet da et allerede aktivt objekt begynner å kjøre den nye koden.

Hvem har nytte av dette?

Endringen er viktig for tjenester der ett objekt holder arbeid i gang mellom forespørsler, for eksempel en langvarig økt, koordinering av flere klienter eller en WebSocket-forbindelse. Den utsatte overgangen gir et tidsrom der objektet kan fullføre aktiviteten det holder på med, eller gå i dvale før det oppdateres. For WebSocket presiserer Cloudflare en betingelse: Forbindelser som bruker Hibernation API, forblir tilkoblet når objektet tar i bruk ny kode etter dvalemodus.

Det praktiske rådet til teamet er å finne ut hvilke aktive objekter som kan være opptatt i mer enn noen minutter, og undersøke hvilket WebSocket-API som brukes. Dette avgjør om den nye utrullingsrekkefølgen gir applikasjonen en mulighet til en smidig overgang, eller om forbindelsen avsluttes ved en tvungen oppdatering.

Fem minutter er et tidsvindu, ikke en garanti

Cloudflare beskriver utsatt oppdatering som «best effort»: Objektet kan tilbakestilles tidligere, for eksempel ved oppdatering av kjøremiljøet. Hvis det ikke har gått i dvale innen den maksimale forsinkelsen er over, tar plattformen i bruk den nye versjonen ved å tilbakestille objektet. Viktig tilstand bør derfor lagres i varig lagring, og operasjoner bør utformes med tanke på mulig omstart. Cloudflares dokumentasjon anbefaler å lagre tilstand som skal overleve utrullinger, i stedet for å stole på minnet i den aktive instansen.

Team kan overstyre oppførselen i Durable Objects-konfigurasjonen: De kan velge umiddelbar oppdatering eller angi en annen tidsfrist for den utsatte overgangen. Umiddelbar oppdatering kan være nyttig når den nye versjonen må tas i bruk med én gang, for eksempel ved en kritisk feilretting. En lengre forsinkelse kan gi objektene mer tid, men forlenger også perioden der noen instanser kjører den gamle versjonen.

Dette bør du kontrollere før neste utrulling

Kontroller at forespørsler mellom Worker og Durable Object er kompatible i perioden der de kan kjøre ulike versjoner. Sjekk at kritisk tilstand lagres i lagring og ikke bare i minnet. For WebSocket bør du finne ut om applikasjonen bruker Hibernation API: Vanlige forbindelser kan bli avsluttet når oppdateringen tas i bruk. Hvis utrullingen krever umiddelbar overgang, må du kontrollere at riktig modus er valgt eksplisitt, i stedet for å stole på den nye standardinnstillingen.

Cloudflare har dermed endret standardavveiningen ved utrulling: Aktive objekter får begrenset tid til å gå naturlig over, samtidig som teamene fortsatt kan fremskynde oppdateringen gjennom konfigurasjon. Det viktigste for utviklere er å kontrollere kompatibiliteten mellom gammel og ny versjon, at tilstanden er lagret, og hvilken type WebSocket som brukes, før neste utrulling.