From the documentation, is not yet possible to move it, and from what @brett explained me recently ( https://discord.com/channels/595317990191398933/773219443911819284/1078750543209566320 ), and if I understood correctly, there is a relocate only at the stub association stage. So if you have created a Id associated somewhere in the world but later you request for the 1st time the stub with a locationHint, this should move it this new location.

No, I mean, is it possible to see what “region” an already existing DO is in? I don’t need to move it, I just need to know where it is

You can start the DO and call https://1.1.1.1/cdn-cgi/trace

then you extract the colo information 🙂

but in theory you should also got it from request.cf.colo, but for theses 2 solutions, you need to run the DO

But if you want to known that from the generated ID, I suppose you can reverse the generated kind-of UUID, if I've understood well, the location is used in the generation of this id

No, I got that, but I meant specifically the region the DO would be in, if I spawned it with

locationHint

. I can do a manually mapping from colos to regions, but iirc, they aren't 100% stable yet.

Understood. Yep, as you said it's not stable, new DO will expands to new colos in the future. I suppose in the CF source code, there is a kind of mapping that match the closest "installed" colo. I don't known if this code is open, but could help... or do indeed a manual mapping, but this require to adjust it time to time...

hiyo, is it possible to add a (brand-new) DO to an existing pages project? I see I can add workers by simply adding a new thing to

functions/helloworld.ts

, but I can't add my

functions/counter.ts

and have it recognized by

wrangler dev

this is a Qwik project, if that helps

it seems like 1 workaround is to have them as separate deployments (as suggested by https://github.com/remix-run/remix/discussions/3066) or do the advanced mode so that they could be all in 1 repo and managed by a wrangler.toml, but that conflicts with my framework's choices

They can be in the same repo because you have to deploy the DO separately from Pages anyway. I have a folder

./durable-objects

at the same level as

./functions

in my repo. Put the wrangler.toml file for the Worker/DO in the

./durable-objects

folder and run

wrangler publish

from that folder whenever you update. I'm constantly forgetting that step and wondering why my smoke tests fail though so I keep promising myself I'm going to automate the publish as part of my Pages build but I have yet to do it.

ah, even if they can be represented as migrations in the wranglers.toml it must be manually deployed?

it feels like that's a missing part to the Pages solution

since you can toss in regular workers

Am I right with this calculation of a cost of $4.15 per month for a Durable Object to run 24/7?

86400 seconds x 128 MB = 11059200
11059200 / 1000 (1GB) = 11059.2
11059.2 x 30 (30 days) = 331776
331776 / 1000000 (million) = 0.331776
0.331776 x $12.50 = $4.1472

I didn't know you could "toss in regular workers" to Pages so my info may be outdated... unless you are referring to Pages advanced mode?

As far as I know wrangler.toml is ignored by Pages CI. I think I remember seeing somewhere that now

wrangler pages dev

will pull from it though.

For a single Durable Object, leaving it running 24/7 would make it fall under the "free" allotment of GB-S for Durable Objects.

That's very similar to what I came up with when I calculated it. But as HW said, running a single one for a month is included in the base paid tier

in my experience at least, you toss them into the

functions

folder and they will get compiled when you run

wrangler pages dev

(from TS even, automagically), this is not in Advanced mode though

but the TS file that exports a class that represents my DO will not show up in the transpiled output

but maybe because these are stateful there's more hoops to jump through

Pages are workers yeah but some features arent exposed through them. Pages is basically opinionated way to write and deploy workers so durable objects as part of a pages worker isnt exposed yet. Though you can bind to durable objects that other workers expose.

I am trying to run a background promise to drain logs in a durable object that looks like this:

const res = new Response("broadcasted")
logger.Drain()
return res

With

logger.Drain()

looking like:

async (lines) => {
  console.log("draining logs!")
  await googleDestinationFunction(lines, c.env)
  console.log("done!")
}

Looking at my execution logs within cloudflare, I see only the

draining logs!

log, but not the

done!

log. I've also tried returning the

googleDestinationFunction

log directly (which also contains logs that I do not see) and it just seems like the DO is exiting once the promise starts running... It is my understanding that the DO should let any other promises run the in background, correct?

how can I define just the DO? https://github.com/cloudflare/durable-objects-typescript-rollup-esm suggests deploying a DO + a worker that reads it, I'll be using bindings from a Pages project

answer: it has to have a worker, doesn't need a fetch handler, just has to exist

Note too that you can disable the

workers_dev

route, so the Worker itself cannot incur any Requests.

in this example, would it look like

export default {}

? https://github.com/cloudflare/durable-objects-template/blob/master/src/index.mjs#L3

where? in _routes.json?