Michael JohnsonAprès un déploiement, un Cloudflare Durable Object actif peut désormais continuer à fonctionner avec sa version actuelle du code jusqu’à son entrée en veille, ou jusqu’à l’expiration du délai défini. Le 30 octobre, Cloudflare a défini les mises à jour différées comme comportement par défaut, avec un délai maximal de cinq minutes. Pour les développeurs, cela modifie le comportement des objets déjà actifs pendant le déploiement : la mise à jour n’interrompt pas nécessairement leur fonctionnement immédiatement, et les connexions WebSocket prises en charge peuvent être conservées lors du passage à la nouvelle version.
Ce qui se passe pendant un déploiement
Les Durable Objects sont des objets adressables dotés d’une identité et d’un état persistants, que Cloudflare utilise notamment pour coordonner des clients, gérer des tâches de longue durée et des sessions WebSocket. Une seule version du code s’exécute à la fois pour un objet donné. Un remplacement immédiat peut donc réinitialiser l’instance active et interrompre le travail ou les connexions.
Le comportement par défaut est désormais une transition différée. Après le déploiement, l’objet actif continue de traiter les requêtes avec l’ancienne version. S’il entre en veille avant l’expiration du délai, la nouvelle version sera lancée à la prochaine requête. Si les cinq minutes se sont écoulées alors que l’objet est toujours actif, il est réinitialisé et adopte la nouvelle version. Le déploiement du Worker se termine indépendamment : le délai concerne le moment où un objet déjà actif commence à exécuter le nouveau code.
À qui cela profite
Ce changement concerne les services dans lesquels un objet maintient une activité entre les requêtes : par exemple, une session de longue durée, la coordination de plusieurs clients ou une connexion WebSocket. La transition différée crée une fenêtre pendant laquelle l’objet peut terminer naturellement son activité en cours ou s’endormir avant la mise à jour. Pour les WebSockets, Cloudflare précise une condition distincte : les connexions utilisant l’API Hibernation restent connectées lorsque l’objet adopte le nouveau code après être entré en veille.
En pratique, l’équipe doit déterminer quels objets actifs risquent de rester occupés plus de quelques minutes et vérifier quelle API WebSocket est utilisée. Cela permet de savoir si le nouveau processus de déploiement donnera à l’application la possibilité d’effectuer une transition en douceur ou si la connexion sera interrompue lors d’une mise à jour forcée.
Cinq minutes : une fenêtre, pas une garantie
Cloudflare décrit les mises à jour différées comme une tentative au mieux : un objet peut être réinitialisé plus tôt, par exemple lors d’une mise à jour de l’environnement d’exécution. S’il n’est pas entré en veille à la fin du délai maximal, la plateforme applique la nouvelle version en le réinitialisant. Il faut donc enregistrer les données importantes dans un stockage persistant et concevoir les opérations en prévoyant qu’elles puissent être relancées. La documentation de Cloudflare recommande de conserver l’état qui doit survivre aux déploiements, plutôt que de compter sur la mémoire de l’instance active.
Les équipes peuvent remplacer ce comportement dans la configuration des Durable Objects : elles peuvent définir le mode de mise à jour immédiate ou choisir un autre délai pour la transition différée. Le mode immédiat est utile lorsque la nouvelle version doit prendre effet sans attendre, par exemple pour un correctif urgent ; un délai plus long peut donner davantage de temps aux objets, mais prolonge aussi la période pendant laquelle certaines instances utilisent l’ancienne version.
Points à vérifier avant le prochain déploiement
Vérifiez la compatibilité des requêtes entre le Worker et le Durable Object pendant la période où ils peuvent fonctionner avec des versions différentes. Assurez-vous que l’état critique est enregistré dans le stockage et pas seulement en mémoire. Pour les WebSockets, vérifiez si l’application utilise l’API Hibernation : les connexions ordinaires peuvent être interrompues lors de l’application de la mise à jour. Si le déploiement exige une transition immédiate, vérifiez explicitement le paramètre de mode au lieu de vous fier à la nouvelle valeur par défaut.
Cloudflare a donc modifié le compromis par défaut lors des déploiements : les objets actifs disposent d’un délai limité pour effectuer une transition naturelle, tandis que les équipes gardent la possibilité d’accélérer la mise à jour via la configuration. Pour les développeurs, le plus important est de vérifier la compatibilité entre les anciennes et les nouvelles versions, la persistance de l’état et le type de WebSocket avant le prochain déploiement.
