Durable Objects state during lifecycle events

I’m building out a proof of concept to move portions of our infrastructure to durable objects. As part of that, I need to answer a set of questions. The main one I’m struggling to find an answer to online is:

If a durable object is processing a request and has in-memory state. What happens to that request, object, and its associated state if I were to publish a new version of the durable object?

If there is any existing documentation on this process I’d appreciate being pointed in the right direction. Thanks!

When the script backing a Durable Object namespace is upgraded we disable the persistent storage API of the old instance(s) and disconnect any connected websockets. New requests will land in the new instance, but any old ongoing requests are able to send a response so long as they don’t throw an error first (e.g. by trying to use the storage API).

Thanks for the quick reply!

Does that mean that if it needs to persist its current state it will fail during this process? Am I right in assuming the new object is created without any of the in-memory state of the old instance?

Does that mean that if it needs to persist its current state it will fail during this process?

That’s right, we wanted to avoid having split brain, where one object might persist stale data after the new object has already served a request and made changes to the persistent state itself.

For some related information, see: https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/

If you have requests here let us know. We have discussed a few ideas here. I could imagine some users would rather old requests have a chance to complete (including storage operations), and new ones would have to wait on the old object to complete work before they began processing. Other users might want the newest code to run immediately. We do want to avoid split-brain, though…

(I think we should disconnect or maybe replay normal HTTP requests too, so that we don’t have temporary split-brain of the transient state.)

Right, that makes perfect sense. There needs to be some point at which you cut things off so there are no staleness issues.

For our use case, the second option requiring old objects to have completed their work before being replaced would be perfect. Is there any way to tell if the currently deployed durable objects are processing? (I’ve searched the docs and looked at wrangler itself and I can’t see anything like that)

Currently the only behavior that exists is that existing requests can complete if they don’t touch storage. In the long term this probably needs to be a user configurable option (per namespace).

For now, if you use storage your best bet is to capture the error that is thrown back to the eyeball worker from the failed fetch, and retry the request, checking storage in the new DO request to see what did or didn’t complete. It should throw a TypeError with the message The Durable Object's code has been updated, this version can no longer access storage.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.