Cloudflare Developers•4y ago

Debugging DO with Vanessa

Sorry, meant the other way around.

8 Replies

Hello, I’m Allie!OP•4y ago

We can keep talking here, @codefrau.

codefrau•4y ago

Huh what's this? a thread on discord?!

Hello, I’m Allie!OP•4y ago

Cool, right? New Features!

codefrau•4y ago

... and it will disappear after a day?

Hello, I’m Allie!OP•4y ago

Archived. It will still be there, just out of the way.

codefrau•4y ago

ah okay well I'm just curious what the policy is on where an object is resumed ... and if that is "sticky", meaning it will tend to live in that new colo from then on (until it's moved again)

Hello, I’m Allie!OP•4y ago

@codefrau So here's how I understand the lifecycle of Durable Objects(Take it with a grain of salt, as I am not a Cloudflare

Employee):

1. When a Durable Object is first created, it's code is uploaded and deployed like normal, to all DO-Ready Colos. Not much else happens.
2. Once it is triggered for the first time, it finds the nearest colo to the incoming request that has DO capabilities, and spins up an instance, along with requisitioning storage there, and in a few other colos.
3. The DO processes the request, and any calls to storage are both processed in the DO-Colo, and the Replication Colos.
4. Step 3 repeats as long as three things do not occur:
  a. The DO is wiped by `deleteAll`,
  b. The Namespace is deleted via Wrangler,
  c. The DO Instance times out after a certain amount of time.
5. If the DO Instance is terminated due to it timing out, the Isolate running it is shut down, but the main storage and replications remain.
6. When a worker triggers the DO again, it finds the nearest DO-Ready colo, and spins up a new isolate with your code, then migrates the storage and replications accordingly.
7. Go back to step 3.

1. When a Durable Object is first created, it's code is uploaded and deployed like normal, to all DO-Ready Colos. Not much else happens.
2. Once it is triggered for the first time, it finds the nearest colo to the incoming request that has DO capabilities, and spins up an instance, along with requisitioning storage there, and in a few other colos.
3. The DO processes the request, and any calls to storage are both processed in the DO-Colo, and the Replication Colos.
4. Step 3 repeats as long as three things do not occur:
  a. The DO is wiped by `deleteAll`,
  b. The Namespace is deleted via Wrangler,
  c. The DO Instance times out after a certain amount of time.
5. If the DO Instance is terminated due to it timing out, the Isolate running it is shut down, but the main storage and replications remain.
6. When a worker triggers the DO again, it finds the nearest DO-Ready colo, and spins up a new isolate with your code, then migrates the storage and replications accordingly.
7. Go back to step 3.

codefrau•4y ago

Sounds about right. Another crucial part of the design is that DO ids are cached in the originating colo, so it knows where to send the requests. And now that I think about it, that is likely why “moving” the DO is sticky, because otherwise there would be unnecessary cache invalidations.

Gaming

Programming

Debugging DO with Vanessa