Em 5 de novembro de 2026, a Cloudflare mudou o comportamento padrão das chamadas a Durable Objects (o componente de estado com coordenação dos Workers). O runtime agora repete sozinho chamadas fetch() e RPC que falham com um erro marcado como repetível antes de chegar ao objeto. Ninguém precisa ativar nada: vale para chamadas feitas por um Worker ou por outro Durable Object.
O que o runtime passou a fazer
Segundo a documentação de retries automáticos, o padrão é até cinco tentativas no total (a original mais quatro repetições), com espera exponencial e variação aleatória entre elas. Nenhuma repetição começa mais de 10 segundos depois do início da chamada original.
O runtime repete em dois casos: quando a requisição não chegou ao objeto (por exemplo, porque ele estava reiniciando ou mudando de máquina) e quando a conexão caiu sem que o runtime saiba se o objeto recebeu a chamada. No segundo caso, a repetição leva a mesma identidade da primeira tentativa, e o objeto a rejeita se já tiver recebido a original. Pela documentação, um método nunca roda duas vezes por causa de uma repetição.
Ficam de fora erros lançados pelo seu próprio código, erros com .overloaded verdadeiro, respostas HTTP de erro como um 500, corpos em ReadableStream, argumentos RPC com streams, stubs ou funções, chamadas com encadeamento de promessas (promise pipelining) e stubs recebidos de outro Worker em vez de criados pelo namespace. As repetições não contam no limite de subrequisições.
Quem precisa olhar agora
Times com produto em Workers que usam Durable Objects para carrinho, sessão, fila, sala de chat ou contador. O caso que exige atenção é o código que já envolve as chamadas ao objeto num laço de retry próprio. A Cloudflare avisa no próprio changelog que cada tentativa do seu código passa a incluir as do runtime. Um laço com três tentativas pode virar até quinze envios ao objeto e, no pior caso, segurar a requisição do usuário por 30 segundos ou mais antes de devolver o erro, já que cada tentativa sua pode esperar até 10 segundos pelas repetições do runtime. A conta é minha, a partir dos limites padrão documentados.
Quem nunca escreveu retry para Durable Objects ganha uma proteção contra falhas curtas sem mexer em nada. Para esse grupo, o efeito visível tende a ser menos erros esporádicos e alguma latência a mais nas chamadas que antes falhariam rápido.
O que fazer
Não há prazo, porque a mudança já está em vigor. O trabalho é uma revisão de código:
- Procurar laços de retry em torno de stubs de Durable Objects. Onde o seu código já controla as tentativas, reduzir o número delas ou criar o stub com
retry: { maxRetries: 0 }emget()ougetByName(). O campo aceita de 0 a 10 repetições, etimeoutMsaceita de 500 a 60.000 milissegundos. - Rever os tempos de espera das rotas que chamam objetos. Um teto de 10 segundos para iniciar repetições pode não caber numa rota com tempo de resposta curto; nesse caso, baixar
timeoutMsno stub. - Marcar com
retryable(), decloudflare:durable-objects, só os métodos idempotentes, aqueles em que rodar duas vezes deixa o mesmo resultado (gravar uma quantidade, e não somar um item). Sem a marca, quando a conexão cai depois que o método começou, o objeto recusa a repetição e o erro chega ao seu código, como antes.
Para usar retryable() e a opção retry, o projeto precisa do Wrangler 4.158.0 ou posterior. As repetições em si não dependem dessa atualização.
O que ainda não está claro
A documentação não diz como as repetições aparecem nos logs e nas métricas de uso, então ainda não dá para saber se um aumento de latência no painel vem delas. Também não há números sobre com que frequência essas falhas acontecem em produção, o que deixa sem resposta quanto de erro esporádico a mudança deve eliminar. Por fim, a nota trata de chamadas por stubs criados no namespace; quem passa stubs entre Workers via RPC continua sem repetição automática e precisa manter o tratamento atual.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
