Error handling
Any uncaught exceptions thrown by a Durable Object or thrown by Durable Objects’ infrastructure (such as overloads or network errors) will be propagated to the callsite of the client. Catching these exceptions allows you to retry creating the DurableObjectStub
and sending requests.
JavaScript Errors with the property .retryable
set to True are suggested to be retried if requests to the Durable Object are idempotent, or can be applied multiple times without changing the response. If requests are not idempotent, then you will need to decide what is best for your application.
JavaScript Errors with the property .overloaded
set to True should not be retried. If a Durable Object is overloaded, then retrying will worsen the overload and increase the overall error rate.
It is strongly recommended to retry requests following the exponential backoff algorithm in production code when the error properties indicate that it is safe to do so.
Durable Objects can throw exceptions in one of two ways:
- An exception can be thrown within the user code which implements a Durable Object class. The resulting exception will have a
.remote
property set toTrue
in this case. - An exception can be generated by Durable Object’s infrastructure. Some sources of infrastructure exceptions include: transient internal errors, sending too many requests to a single Durable Object, and too many requests being queued due to slow or excessive I/O (external API calls or storage operations) within an individual Durable Object. Some infrastructure exceptions may also have the
.remote
property set toTrue
— for example, when the Durable Object exceeds its memory or CPU limits.
Refer to Troubleshooting to review the types of errors returned by a Durable Object and/or Durable Objects infrastructure and how to prevent them.
This example demonstrates retrying requests using the recommended exponential backoff algorithm.