El 5 de noviembre de 2026, Cloudflare cambió el comportamiento predeterminado de las llamadas a Durable Objects (el componente de estado con coordinación de Workers). El runtime ahora reintenta por su cuenta las llamadas fetch() y RPC que fallan con un error marcado como reintentable antes de llegar al objeto. No hay que activar nada: aplica a llamadas hechas por un Worker o por otro Durable Object.
Qué hace ahora el runtime
Según la documentación de reintentos automáticos, el valor predeterminado es de hasta cinco intentos en total (el original más cuatro reintentos), con espera exponencial y variación aleatoria entre ellos. Ningún reintento empieza más de 10 segundos después del inicio de la llamada original.
El runtime reintenta en dos casos: cuando la solicitud no llegó al objeto (por ejemplo, porque se estaba reiniciando o moviendo a otra máquina) y cuando la conexión se cayó sin que el runtime sepa si el objeto recibió la llamada. En el segundo caso, el reintento lleva la misma identidad que el primer intento, y el objeto lo rechaza si ya recibió el original. Según la documentación, un método nunca se ejecuta dos veces por un reintento.
Quedan fuera los errores lanzados por tu propio código, los errores con .overloaded en verdadero, las respuestas HTTP de error como un 500, los cuerpos en ReadableStream, los argumentos RPC con streams, stubs o funciones, las llamadas con encadenamiento de promesas (promise pipelining) y los stubs recibidos de otro Worker en lugar de creados desde el namespace. Los reintentos no cuentan para el límite de subsolicitudes.
Quién debe revisarlo ahora
Equipos con productos en Workers que usan Durable Objects para carrito, sesión, cola, sala de chat o contador. El caso que exige atención es el código que ya envuelve las llamadas al objeto en un bucle de reintento propio. Cloudflare advierte en el propio changelog que cada intento de tu código pasa a incluir los del runtime. Un bucle con tres intentos puede convertirse en hasta quince envíos al objeto y, en el peor caso, retener la solicitud del usuario 30 segundos o más antes de devolver el error, ya que cada intento tuyo puede esperar hasta 10 segundos por los reintentos del runtime. La cuenta es mía, a partir de los límites predeterminados documentados.
Quien nunca escribió reintentos para Durable Objects obtiene protección contra fallos breves sin cambiar nada. Para ese grupo, el efecto visible probablemente será menos errores esporádicos y algo más de latencia en las llamadas que antes fallaban rápido.
Qué hacer
No hay plazo, porque el cambio ya está en vigor. El trabajo es una revisión de código:
- Buscar bucles de reintento alrededor de stubs de Durable Objects. Donde tu código ya controla los intentos, reducir su número o crear el stub con
retry: { maxRetries: 0 }enget()ogetByName(). El campo acepta de 0 a 10 reintentos, ytimeoutMsacepta de 500 a 60.000 milisegundos. - Revisar los tiempos de espera de las rutas que llaman a objetos. Un techo de 10 segundos para iniciar reintentos puede no encajar en una ruta con un tiempo de respuesta corto; en ese caso, bajar
timeoutMsen el stub. - Marcar con
retryable(), decloudflare:durable-objects, solo los métodos idempotentes, aquellos en los que ejecutar dos veces deja el mismo resultado (fijar una cantidad, no sumar un artículo). Sin la marca, cuando la conexión se cae después de que el método empezó, el objeto rechaza el reintento y el error llega a tu código, como antes.
Para usar retryable() y la opción retry, el proyecto necesita Wrangler 4.158.0 o posterior. Los reintentos en sí no dependen de esa actualización.
Qué aún no está claro
La documentación no dice cómo aparecen los reintentos en los logs y en las métricas de uso, así que todavía no se puede saber si un aumento de latencia en el panel viene de ellos. Tampoco hay cifras sobre la frecuencia de estos fallos en producción, lo que deja abierta cuántos errores esporádicos debería eliminar el cambio. Por último, la nota trata de llamadas mediante stubs creados desde el namespace; quien pasa stubs entre Workers por RPC sigue sin reintento automático y debe mantener su manejo actual.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
