it just started an infinite loop when starting the dev server 🤣

doesn't seem possible unless there is another way to specify the binding

Oh it's possible it's broken in local dev lol, that's not a common use case

I'd recommend you just import your normal fetch method, since they're in the same codebase, and use that

hmm it kicks off a long running process in the worker inside a waitUntil. I think this could cause trouble when running inside the DO

Ah that could be a problem, yes

Doing a normal fetch is probably your best bet then

can you call another durable object from inside a different durable object? I'm receiving a weird miniflare error

[mf:err] Unhandled Promise Rejection: TypeError: The "string" argument must be of type string or an instance of Buffer or ArrayBuffer. Received null

but I am not passing

null

. I even hardcoded a string just to make sure

Yes you can call a durable object from inside a different durable object. Have you tried publishing it, or just miniflare?

nevermind, sorry, I'm not sure what was happening there but it is working now

Is there any way for a DurableObject to know it's migration number or deployment id at run time?

what are you trying to accomplish?

The durable objects store event history and may need to recalculate a snapshot of state if their code changes.

Current deployment id would be fine, but it doesn't seem like its available

I guess I'm not understanding - when you update code, running DOs are going to be removed from memory and the constructor in the new code is going to run for new requests. What decision will that constructor make based on deployment id that it couldn't make based on stored data (or on constants in the code itself)?

The durable object stores computed state to save time. If the algorithm is ever updated we may need to recompute state.

This is an application level thing not an infra/ops thing.

I was going to use the deployment or migration id as a flag to let the do it should throw away it's old stored state and instead recompute and store a snapshot of that. It can be quite expensive in some cases.

Hello y'all. Newbie here. I wanted to check in to see if anyone has some time to discuss how to build the architecture for a simple word game; using Durable Objects, and Websockets on Cloudflare Workers (obvi).

If it's not obvious from the stored state that it needs to be recomputed, you're going to have to put something in storage that indicates what version it was computed with. Deployment id, even if you had access to it, seems less convenient than a constant for version in the code that you increment only for code updates that require recomputation.

Gave it some more thought and this is the more prudent option.

Does every durable object invocation get its own subrequest limit?

yes, and when it starts handling a new request it's reset to 1000

example: DO instance 1 wakes up from an alarm call and does 10 KV gets, it then calls a second DO instance, how many KV gets can the second instance do?

oh! nice

A completely different instance wont share limits. When the same instance handles many requests I'm not entirely sure how that works but I assume on a request coming in the limit gets set back to 1000 rather than each request getting its own limit of 1000 requests.

so what is the practical limit these days on the amount of terminated ws connections one DO can hold indefinitely, assuming the DO is doing nothing but keeping them around in an array and republishing an incoming message outbound to all connections?

i thought a limit of 500 would be safe, but seeing it plateau at around a hundred - and can't tell if this is due to usage, or the DO running out of resources

There is a hard limit of 1024 connections per instance somewhere in workerd - not documented anywhere though afaik - I've had success with 150, didn't test anything above