hmm I don't recognize the timeout error, is that our error or yours?

oh I found it

I can only have 10000 timeouts, after that setTimeout gives me that error.

I see, the limit on setTimeout()s

which was designed long before Durable Objects. We figured a single HTTP request couldn't possibly need more than 10,000 setTimeout() calls, heh.

lol

I believe we're planning to fix that, too.

Oh I hope so. that would be a deal breaker, unless you can suggest a work-around

Are you planning to fix

Cannot clear a timeout created in a different request context

too?

Yes.

Is wrangler tail working okay using DO? My did show nothing on the worker side (modules of course) and nothing on DO side...

@User Wrangler tail doesn't work with DOs yet.

But should listen regular worker that is binded to the DO right?

Yeah, Tail should work on the calling worker. What are you making your test requests from?

@User well I just type “wrangler tail” the they connect to to calling worker but never prints anything. When I used the KV over a regular worker without modules worker. After I changed to modules+DO a month ago stopped to work.

* do you have other non-modules workers that

wrangler tail

works fine with? * for the modules + DO worker, what is sending requests to the worker? Is it you that's sending test requests, or is it a worker serving traffic? * is the modules + DO worker on

workers.dev

, or a route on a zone?

On that project i only have module worker, but i can setup a new one here just to test that; The main site is hosted at cloudflare pages and call api.domain.tld request that is routed to a worker;

Under what circumstances would a DO not be created in the same colo as the first worker connecting to it? I have a colleague in Toronto, and her worker is in YYZ, but the DO was created in Chicago (ORD). What can I do to prevent this from happening? (The script is on workers.dev but there is an enterprise trial plan covering it) Also, workers in India and New Zealand create DOs in Hong Kong, Argentina goes to Miami etc..

> Not all Cloudflare locations support Durable Objects yet, so objects may not be created in exactly the same point-of-presence where they are first requested. Ah. Thank you 🙂

Is there a way to get a fast feedback cycle with Durable Objects / web sockets i.e. develop locally with live reload and then only deploy only when working locally. I'm currently deploying to test every change is there a better way? For example the Chatroom is there a way to get that running locally: https://github.com/cloudflare/workers-chat-demo

hi there. Any pointers to a sane solution for simulating something akin to a game loop on a durable object? I don't think using SetInterval feels right, and i need a headless solution so something like RequestAnimationFrame is also not a good idea

@User I tested on a new project (non module) and did work as expected.

Also, about the Durable Objects itself, any plan to support more jurisdictions ? Analog to GDPR, here in Brazil we need to keep the data in our county because of our LGPD (our version of GDPR)

We definitely plan to add more jurisdictions eventually. But, right now we're focused on more basic product needs. I'm not sure exactly when we'll start being able to add more jurisdictions.

Right now the only option is to deploy. We know this is not a very good experience. We're actively working on a way to preview DO code without actually deploying it, but it's a surprisingly hard problem due to the nature of Durable Objects. I think we'll have something in 2-3 months, but I'm not completely sure.

Forgot to post this here, but I made a small dashboard that keeps track of where durable objects are created. https://where.durableobjects.live/

My work-around for no local development is to have a watch in my

package.json

, which will build and deploy to

dev

as soon as I save. Then I just switch to the browser and reload.

{
  ...
  "scripts": {
    "start": "npm-watch deploy-dev",
    "deploy-dev": "wrangler publish --env dev",
    ...
  },
  "watch": {
    "deploy-dev": "*.js"
  },
  "devDependencies": {
    "npm-watch": "^0.9.0",
    ...
  }
}

Neat. Not sure why it connected me via Dallas (DFW) - my own workers / DOs always are in LAX? I was curious too, added a map for my tests:

is it possible it’s because it’s under a free account? that or there’s some sort of other path condition about the DO itself…