My habit of completely not caring about my DO names and making them random numbers or UUIDs comes in
My habit of completely not caring about my DO names and making them random numbers or UUIDs comes in handy once again!
1Its just annoying cos I have a bunch of data that I want to associate to a specific year, I can rearchitect around it but would rather not
IIf you do this I highly recommend using newUniqueId() rather than idFromName() if you can, it saves a round trip
PI've had this happen before, and I genuinely have no idea what causes it. Maybe different machines or something? But also usually for me when it happens, sometimes when its recreated out of idle later the latency changes again
1I'll wait a bit and see if I get similar results
POh interesting, I didn't know that. Thanks for the tip!
Prn my scheme is usually [IATA of incoming request worker]-[DO type/name]-[some sort of short random number or UUID] so that in logs it shows up a little nicely, but I think I'm just going to go full IDs now
IYeah basically if you use the
idFromName the runtime has to check (globally) whether the DO exists already whereas if you do newUniqueId it's generated in a way that it will always be unique and doesn't need to do that double-checkPOh that makes... a lot of sense. The more you know
1There's a note about it here for reference: https://developers.cloudflare.com/durable-objects/api/namespace/#newuniqueid
PAh, I never used newUniqueId so I guess I missed that. Thanks for the link!
PLooking over the docs again, I am actually kind of curious why there isn't a way to spawn a DO at a specific location or minimal latency to a specific CF POP. I wonder if it's a engineering limitation or just lack of demand (I'm guessing I will probably never get a specific answer)
1Probably just to stop people absolutely spamming new instances in 1 pop
Plmao
Pyeah fair enough
Pback to spinning up lambda instances to pre-emptively create DOs :)
1I'm actually wondering if this is related to my ISP in some way, I'm getting directed to Perth on other Workers not at all related to DOs
PIt very well could be. Maybe your ISP is peered with an interchange in perth?
P1I just got Adelaide which is different again :NotLikeThis:
PThat's so weird
PFor what it's worth, my ISP sends my requests to a datacenter ~400 miles away from me, ISPs are just weird
Pime it's just luck whether or not your ISP is sane with routing
1Melb to Perth is like ~3000km hahaha
1That would be insane routing if so
PI think cloudflare only has a handful of POPs in Australia though
1Melb, Syd, Bris, Adel, Per
1Oh and tas
Pso wherever it's popping out, the closest POPs may be either Adelaide or Perth
1Melb to perth is basicallty bas bad as it gets
Plmao
Phuh
Paccording to that Perth doesn't host DOs
Pthat's strange
1Yeah the DO is in Mel but request being routed through Perth
1Which is even weirder
Phuh.
1
1PIt's just taking the scenic route
P:)
Pdata is going for a little trip
1Should be only a 25% chance a Melb DO goes via Perth
PCould always be load balancing too, who knows what traffic looks like
1I switched to my phone hotspot and get Melb on the cdn-cgi trace but the Worker calls still being routed through Perth. I think I'd better ignore this or it'll send me crazy
1Now while Ive been loooking at this DO site the Perth option has disappeared from Melbourne entirely 
hopefully someone has seen me complaining and is fixing this as we speak
hopefully someone has seen me complaining and is fixing this as we speak1hahahaha yes someone is listening,
2025 is now appearing in SydneyP
LDoubt it
But, yes, your observation and what others said above is mostly true that a DO will be created in the initially created colo if possible. There are cases it will move out of that, like when that colo has network issues and is taken out of the network for a while and the DOs hosted there will move elsewhere in the same region.
In the long-term future, our hope is for DOs to be moving more often closer to requests, but not yet.
But, yes, your observation and what others said above is mostly true that a DO will be created in the initially created colo if possible. There are cases it will move out of that, like when that colo has network issues and is taken out of the network for a while and the DOs hosted there will move elsewhere in the same region.
In the long-term future, our hope is for DOs to be moving more often closer to requests, but not yet.
1And if a DOs storage is deleted using
deleteAll()At the moment, yes, we have a record of all created DOs even without storage. As I said, though, I wouldn't depend on this because we want to change it in the future. Just explaining why you are seeing the stickiness.