Yeah, it's definitely correct today. It's not intended to be a public feature though so for all I know it could change or go away at any point, too.

Would be cool to have the colo on the state object(for metrics, as even within the same region, different colos may have different performance to certain origins), with the understanding that it could change the next time the DO boots

You got a point, but there others cases where is very far, just an example ALG/Algier could fall in France (Paris, Marseille) or Italy (Milan). On a map, Spain / Barcelone could be closest, and why Paris rather than Marseille, it's a non-sense for me

or another solution to our architecture to prevent theses problems of wrong colo for ever, should be to not share a same DO for the users, and to create 1 DO per user, so at least, this limit the problem, some could be installed on a far distance, but not everybody. I suppose this will cost us more money to manage 1 DO / user rather than 1 DO / colo...

when you say "for performances + GDPR", if you care about gdpr, you should use the gdpr jurisdiction rather than trying to make assumptions about where things are created

Indeed, it's why I wrote in the beginning of my explanation « I don't mention the req.cf.isEUCountry and juridiction() subnamespace to make it simple » 😉 I known there is also this juridication factor for EU countries 🙂

there is 2 differents mechanisms, one inside the EU, and another outside of EU. But for both, the problem is the same ( excepted inside the EU with force the juridication NS to fall at least on a server hosted per a EU country )

Also, secondary question, does location have any effect on where DOs are spawned when using location hints?

> Would be cool to have the colo on the state object plus ten - I realize this is almost a religious objection, since we're not supposed to care - but it is incredibly useful in practice for debugging, mapping to outages, performance, etc - also same info exposed in request.cf.colo

Unless you're holding a DO open and idle, I'm not sure it'd cost more. Or I guess if you have to duplicate a lot of data. But if you don't, you're using the same requests/storage/active-time whether it's 1 Object or many, no?

Not sure what you mean, but I think the answer is no?

locationHint

is respected regardless of where the client is (as long as the DO didn't exist yet)

I mean like, if I provide a

locationHint

in

weur

, and my request comes from London, am I more likely to have the DO spawn in London/in the UK? Or if I spawn it in

oc

, and my closest Oceanic-DO-supported colo is Sydney, is it more likely to appear there?

I know it will never guarantee anything, but does it take my location into account?

Ah, if a nearby DO colo is in the region it'll be used. Not always the nearest though, it does the same "pick one near-ish enough"

Just wondering whether it would be worth adding to the WDL global ping list, or just running it via a CRON trigger. Thanks for the info, brett!

I'm getting the exception "Durable Object storage operation exceeded timeout which caused object to be reset." I don't believe I'm using deleteAll() anywhere in my code (referenced in the docs as a potential cause). Any advice on troubleshooting this beyond general best practices for JS applications? Is there a way to get a stack trace?

It doesnt only happen with deleteAll(), it can happen to any storage operation. Its not really anything you can fix (probably), I assume its not happening consistently for you? If it is then you might need to slow down the rate of storage operations you do by sharding

Unfortunately, the app data is already heavily sharded, I'll try to dig into exactly when it's happening. Do you know if those exceptions can be caught and logged in JavaScript?

They can be caught outside of the DO only afaik, so you would have to add a try catch around the call you make into the DO

Damn, that's frustrating. I don't mean to disparage the product, but is anyone using DOs seriously in production? My use case is currently pretty small, currently we're in a private beta. I'm trying to imagine dealing with this type of issue with a big app and paying customers.

Having these types of request limits is quite normal across many PaaS, but there has to be a better way to diagnose the issue than seeing failed requests from an upstream worker.

Cloudflare uses them in production for many things. Cache purging, R2 metadata, Waiting rooms, D1

Gotcha, that's interesting.

How frequently are you seeing that error?

Started today and based on when it showed up, I think I know generally which part of my app is causing it. I'm definitely not complaining about having those limits, I'm just trying to figure out how I'm going to troubleshoot and resolve issues like these as my user base grows.

Does keeping a websocket connection open to a durable object prevent the object from ever being evicted? The docs don't seem to say anything about a limit, is this right?

That's right

Wait, actually? I thought there was still a risk of eviction, just maybe a bit lower if there is an active connection…

So if you have a really long task to run, just open a WS connection, and it won’t get evicted?

Well it could be evicted because of a system upgrade or a crash or something, but generally speaking if your object is serving an active request it won't be evicted