Michael JohnsonDopo un deployment, un Cloudflare Durable Object attivo può ora continuare a funzionare con la versione corrente del codice finché non entra in ibernazione, oppure fino alla scadenza del limite impostato. Il 30 ottobre Cloudflare ha impostato per default gli aggiornamenti differiti, con un ritardo massimo di cinque minuti. Per gli sviluppatori, questo modifica il comportamento degli oggetti già attivi durante il rilascio: l’aggiornamento non deve necessariamente interromperli subito e le connessioni WebSocket supportate possono essere mantenute nel passaggio alla nuova versione.
Cosa accade durante il deployment
Durable Objects sono oggetti indirizzabili con identità e stato persistenti, che Cloudflare utilizza, tra le altre cose, per coordinare client, attività di lunga durata e sessioni WebSocket. Per ogni oggetto è attiva una sola versione del codice alla volta. Di conseguenza, una sostituzione immediata può reimpostare l’istanza attiva, interrompendo il lavoro o le connessioni.
Ora lo scenario predefinito prevede il passaggio differito. Dopo il rilascio, l’oggetto attivo continua a gestire le richieste con la versione precedente. Se entra in ibernazione prima, la nuova versione viene avviata alla richiesta successiva. Se trascorrono cinque minuti e l’oggetto è ancora attivo, viene reimpostato e adotta la nuova versione. Il deployment del Worker termina separatamente: il ritardo riguarda il momento in cui l’oggetto già attivo inizia a eseguire il nuovo codice.
A chi è utile
La modifica è importante per i servizi in cui un singolo oggetto mantiene il lavoro tra una richiesta e l’altra, per esempio una sessione di lunga durata, il coordinamento di più client o una connessione WebSocket. Il passaggio differito crea una finestra in cui l’oggetto può terminare naturalmente l’attività in corso o entrare in ibernazione prima di aggiornarsi. Per WebSocket, Cloudflare specifica una condizione: le connessioni che utilizzano l’API Hibernation restano attive quando l’oggetto adotta il nuovo codice dopo l’ibernazione.
In pratica, il team dovrebbe individuare quali oggetti attivi possono restare occupati per più di qualche minuto e verificare quale API WebSocket viene utilizzata. Da questo dipende se il nuovo processo di deployment offre all’applicazione la possibilità di passare gradualmente alla nuova versione o se la connessione terminerà durante l’aggiornamento forzato.
Cinque minuti sono una finestra, non una garanzia
Cloudflare descrive l’aggiornamento differito come best effort: l’oggetto può essere reimpostato prima, per esempio durante un aggiornamento dell’ambiente di esecuzione. Se non entra in ibernazione entro la fine del ritardo massimo, la piattaforma applica la nuova versione tramite un reset. È quindi importante salvare lo stato critico in un archivio persistente e progettare le operazioni tenendo conto della possibilità che vengano eseguite di nuovo. La documentazione di Cloudflare consiglia di salvare lo stato che deve sopravvivere ai deployment, invece di affidarsi alla memoria dell’istanza attiva.
I team possono modificare il comportamento nella configurazione di Durable Objects: impostare la modalità di aggiornamento immediato oppure scegliere un altro intervallo per il passaggio differito. La modalità immediata è utile quando la nuova versione deve entrare in vigore subito, per esempio per una correzione urgente; un ritardo più lungo può concedere agli oggetti più tempo, ma prolunga anche il periodo in cui alcune istanze usano la versione precedente.
Cosa verificare prima del prossimo rilascio
Verificate la compatibilità delle richieste tra Worker e Durable Object durante il periodo in cui possono usare versioni diverse. Controllate che lo stato critico venga salvato nell’archivio e non soltanto in memoria. Per WebSocket, accertatevi che l’applicazione utilizzi l’API Hibernation: le connessioni normali possono terminare quando viene applicato l’aggiornamento. Se il deployment richiede un passaggio immediato, verificate l’impostazione esplicita della modalità, anziché fare affidamento sul nuovo valore predefinito.
Cloudflare ha quindi modificato il compromesso predefinito durante il deployment: gli oggetti attivi hanno un tempo limitato per passare naturalmente alla nuova versione, mentre i team possono accelerare l’aggiornamento tramite la configurazione. Il controllo più utile per gli sviluppatori, prima del prossimo rilascio, è verificare la compatibilità tra la versione precedente e quella nuova, la persistenza dello stato e il tipo di WebSocket utilizzato.
