Michael JohnsonDespués de una implementación, un Cloudflare Durable Object activo puede seguir funcionando con la versión actual del código hasta entrar en hibernación o hasta que venza el plazo establecido. El 30 de octubre, Cloudflare estableció las actualizaciones aplazadas como opción predeterminada, con un retraso máximo de cinco minutos. Para los desarrolladores, esto cambia el comportamiento de los objetos que ya están en ejecución durante un despliegue: la actualización no tiene por qué interrumpirlos inmediatamente, y las conexiones WebSocket compatibles pueden mantenerse al pasar a la nueva versión.
Qué ocurre durante una implementación
Durable Objects son objetos direccionables con identidad y estado persistentes que Cloudflare utiliza, entre otras cosas, para coordinar clientes, ejecutar tareas de larga duración y gestionar sesiones WebSocket. Cada objeto ejecuta una sola versión del código a la vez. Por eso, si se sustituye inmediatamente, una instancia activa puede reiniciarse e interrumpir el trabajo o las conexiones.
Ahora, el comportamiento predeterminado es una transición aplazada. Tras el despliegue, el objeto activo sigue atendiendo solicitudes con la versión anterior. Si entra en hibernación antes, la nueva versión se iniciará cuando se reciba la siguiente solicitud. Si transcurren cinco minutos y el objeto sigue activo, se reinicia y adopta la nueva versión. La implementación del Worker se completa por separado: el retraso afecta al momento en que el objeto que ya está activo empieza a ejecutar el código nuevo.
A quién beneficia
El cambio es importante para los servicios en los que un objeto mantiene el trabajo entre solicitudes: por ejemplo, una sesión prolongada, la coordinación de varios clientes o una conexión WebSocket. La transición aplazada abre un margen para que el objeto termine de forma natural la actividad en curso o entre en hibernación antes de actualizarse. Para WebSocket, Cloudflare señala una condición específica: las conexiones que usan la Hibernation API permanecen conectadas cuando el objeto adopta el nuevo código tras la hibernación.
La conclusión práctica para los equipos es identificar qué objetos activos podrían permanecer ocupados durante más de unos minutos y averiguar qué API de WebSocket utilizan. De ello depende que el nuevo proceso de despliegue permita una transición gradual en la aplicación o que la conexión se cierre al forzar la actualización.
Cinco minutos: un margen, no una garantía
Cloudflare describe la actualización aplazada como un esfuerzo razonable, no como una garantía: el objeto puede reiniciarse antes, por ejemplo, al actualizarse el entorno de ejecución. Si no ha entrado en hibernación al terminar el plazo máximo, la plataforma aplicará la nueva versión mediante un reinicio. Por eso, el estado importante debe guardarse en almacenamiento persistente y las operaciones deben diseñarse teniendo en cuenta que podrían volver a ejecutarse. La documentación de Cloudflare recomienda guardar el estado que debe sobrevivir a los despliegues, en lugar de depender de la memoria de la instancia activa.
Los equipos pueden cambiar el comportamiento en la configuración de Durable Objects: establecer el modo de actualización inmediata o elegir otro plazo para la transición aplazada. El modo inmediato puede ser útil cuando la nueva versión debe entrar en vigor enseguida, por ejemplo, para una corrección urgente; un plazo más largo puede dar más tiempo a los objetos, pero también prolonga el periodo en que algunas instancias ejecutan la versión anterior.
Qué comprobar antes del próximo despliegue
Comprueba la compatibilidad de las solicitudes entre el Worker y Durable Object mientras ambos pueden estar ejecutando versiones distintas. Verifica que el estado crítico se guarde en almacenamiento y no solo en memoria. En el caso de WebSocket, averigua si la aplicación usa la Hibernation API: las conexiones normales podrían cerrarse al aplicarse la actualización. Si el despliegue requiere una transición inmediata, comprueba la configuración explícita del modo en lugar de confiar en el nuevo valor predeterminado.
En resumen, Cloudflare ha cambiado el equilibrio predeterminado durante los despliegues: los objetos activos disponen de un tiempo limitado para hacer una transición natural, y los equipos conservan la opción de acelerar la actualización mediante la configuración. Antes del próximo despliegue, lo más útil para los desarrolladores es comprobar la compatibilidad entre versiones, la persistencia del estado y el tipo de conexión WebSocket.
