Is it easy to get the durable object storage limit of 50GB raised? Would I be required to get an enterprise account or something like that? I use DOs for collecting some statistics data and leaderboards and it's going to keep growing. I am currently at 10GB, I don't expect to get to 50GB for a while, but I could definitely see it happen eventually and don't want it to be a bad surprise 😅

(I am developing a game with user made levels, for each level I have a DO that collects data on who already played it and what their best time is and maintain a unique player count and average time that way. I am currently planning to also add similar data with keys based on the time for a leaderboard)

in case anyone missed this. 🙂

AFAIK instantiating the stub is only an issue the first time it happens in a datacenter(?), and then it's cached. It would be cached every time in a DO (since it's always going to be in the same datacenter), but I don't think it would make a big difference.

the query object that is available on the worker is coming as empty object to durable object fetch method... anyone can give solution for this?

What do you want to increase it to? 100GB? More? Want to drop me a DM with your accountId and your estimated size?

are you talking about request.cf or something else?

assuming you are talking about request.cf, the request you get in the eyeball worker will have it. If you want it to be present in the request to the durable object, you'll need to forward that request along in the fetch to the DO, e.g.

If instead you just did

await obj.fetch("some url you constructed")

the request.cf isn't going to be automatically passed along

If you do need to construct a different URL you could use e.g.

await obj.fetch("some url", {cf: request.cf})

If I create a durable object and set an alarm for 7 days out and do nothing else with it, would it be considered active for billing purposes the entire 7 days?

no

How do y’all handle initializing properties on a DO from storage? You can make it optional, but then you have to initialize it in the fetch/alarm handlers. You can do it in the constructor with blockConcurrencyWhile, but you still have to guarantee the type checker that the object exists

You'd tell the type checker to ignore it some way or another

Hello 👋 I'm trying to understand the limits when coordinating multiple durable objects. If a durable object makes a fetch request to another durable object, does it "allocate" a new instance (with its memory/CPU limits)? or similar to sub-requests to the same worker, it shares the resource/thread? I guess it allocates a new instance (or re-use the potentially running one) as there is a unique instance running at all time.

Example: If a durable object

A

makes 100 requests to different IDs of durable object

B

, where each of these request are slightly expensive to compute, fine for 128MB and limited CPU when handling one request, but not fine when handling 100 in the same thread. Will it work ? or are the 100 requests potentially going to compete for the 128MB of memory?

Each durable object instance is entirely separate to the others, with it's own memory and storage

Each namespace is guaranteed isolated memory. Multiple instances from the same namespace can spawn in the same memory space.

Unless something has changed somewhat recently that isn't entirely true. It is possible that 2 different durable object instances will share memory. I believe they would have to be the same exported class and on the same server which depending on how many DOs you have running at the same time would be how likely

Oh interesting

I thought they had fixed that

Thank you all! So in my example, it's very likely that the 100 instances of the same namespace will endup sharing memory (probably not the 100, but most)?

they have way more than 100 servers so no

(as the request will come from the same location and will spawn 100 instances as close as possible)

It certainly is possible but I wouldnt say it 100% will happen

It's unclear what strategy cloudflare uses to spawn the durable objects: if a single location receives N requests to N different durable objects in the same namespace, do they try to share the thread as much as possible? if yes, how do they decide when a thread should not handle more requests? how do they avoid a durable object suffering from little memory left because of other instances sharing the same thread?

Hii sir

IIRC, if a request to a Namespace hits the same blade as another active instance, it will be merged, as long as the request queue isn’t overflowing

U have facing this issue, what can I do sir please tell Mee the solution