Durable Object reset errors: code updates vs storage timeouts

TL;DR

In objects with a large number of key-value pairs, deleteAll() can hit that limit and fail, resetting the object. Key fact: each deleteAll() call makes progress before failing, so it is safe to retry until it succeeds.

Steps

1. When you deploy new code, Durable Object instances reset: their in-memory state is gone. Any state already persisted via state.storage is not affected. Design rule: anything that must survive a deploy lives in storage, not in instance fields. If your object "loses data" on deploy, it was never persisted.

1. Storage operations have a time limit to prevent indefinite blocking. In objects with a large number of key-value pairs, deleteAll() can hit that limit and fail, resetting the object. Key fact: each deleteAll() call makes progress before failing, so it is safe to retry until it succeeds. Do not redesign around it; loop the retry.

1. - Treat in-memory DO state as ephemeral by design; persist what matters.

• deleteAll() timeout: retry in a loop, it converges.
• Your account is doing too many concurrent storage operations: back off and retry after a short wait, and spread storage work across requests.

When to use

You are seeing this: "Reset" in Durable Object errors refers to in-memory state. Use this skill when you run into "Durable Object reset errors: code updates vs storage timeouts".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.