Cloudflare Durable Objects calls now retry automatically
The runtime retries fetch() and RPC calls to Durable Objects on retryable errors, up to four times within 10 seconds, without you writing a retry loop.
Cloudflare’s runtime now retries failed calls to Durable Objects on its own, instead of leaving you to write the retry loop. The change, shipped 5 November, covers fetch() and RPC calls made through a stub, whether the caller is a Worker or another Durable Object.
A retry only fires when a call fails before reaching the object, such as during a restart or migration, or when the connection drops before Cloudflare can confirm what happened. By default the runtime makes up to four retries with backoff and jitter, and never starts one more than 10 seconds after the original call. Errors thrown by your own code, and errors marked .overloaded, are never retried. Because a retried call might already have run once, only methods marked safe to repeat get retried at all:
import { retryable } from 'cloudflare:durable-objects';
retryable(MyObject.prototype.setQuantity);You can also override the attempt count, 0 to 10, and the timeout, 500ms to 60 seconds, per stub with the retry option on get() or getByName(). It needs Wrangler 4.158.0 or later.
Why it matters: if you’ve been wrapping Durable Object calls in your own retry logic to survive restarts or network blips, you can delete most of that now, as long as the methods you mark retryable() are genuinely idempotent. Mark a non-idempotent method retryable and a dropped response can make a write apply twice.