btw it has always been available in alarms though, even for long running background tasks

okay yep it is a bug with itty-durable

await this.state.storage.get("data")

returns the correct state

await this.toJSON()

returns the blank data

only happens in the alarm handler after the DO is reset

ok not really a bug but mostly just a very confusing situation... I added this to my DO to set the

userId

from the name into storage:

js
async onLoad() {
  if (!this.userId && this.state.idFromName) {
    console.log("setting userId from state", this.state.idFromName);
    this.userId = this.state.idFromName;
    this.persist();
  }
}

and added this to my alarm handler:

js
if (!this.state.initialized) {
  await this.loadFromStorage();
}

looks much better now 🙂

How many times can I request storage limit increase (or until what size can I request) ? What conditions if any may require my compliance when requesting such limit increases ? Is the 150rps a hard limit that cannot be increased like the storage limit ?

Afaik there pretty much is not a limit for storage increases but at some point they may make you switch to enterprise. I assume the limit is mostly there for abuse and it shouldnt be too hard to get a limit increase, never tried myself though. There is no limits on number of requests per second. But durable objects are single threaded so to a single object you will only be able to handle so many requests before the object gets overloaded. For some very very simple storage requests only, like a counter, you can get somewhere in the thousands of requests per second.

^ there's no fixed limit. If your requests take on average 1ms that's 1,000/s (1ms * 1000 = 1s) But it's up to you on how efficient they are

Hi

Im using cloudflare queues to queue a bunch of links that im scraping, e.g. like 2000 items gets sent to the queue and then a worker picks up 5 items and runs them concurrently in a promise all. The issue im having is i have a max of 50 concurrent connections that i can use with the scraping service so im thinking of using a do apposed to workers and funnel everything though one do apposed to multiple workers picking up items from the queue and hitting my limit. Does it sound like the right approach?

I don't really understand why you need to do that. you can already specify the max concurrency and max number of items per batch. so if you have 10 concurrent queue consumers and 5 items per batch, for example, you would never go over the limit (unless I'm missing something)

(I personally use DOs as a queue instead of using CF Queues but your use case sounds like its better to stick with queues)

(also make sure to do retrying with exponential backoff when calling the service just in case)

Hey 👋 Is there any way to check if a Durable Object has been instantiated using its ID without instantiating it? Basically, I have a backend in us-central1 that will make some requests to the worker, and I want to do a logic like:

const doStub = DO_NAMESPACE.get(id);
const doInstantiated = await doStub.exists();

if (doInstantiated) {
   return doStub.fetch(request)
} else {
  // Handle the request another way
}

The goal is to avoid creating DOs near the us-central1 region since DO currently can't move between locations, and I'd like to optimize them to be as closed from the first end-user making a request to it, and not out backend.

I don't think so, no. you could make a second DO that just keeps track of the IDs of this DO's instances

You can fetch the DO and have some route that returns whether the DO has been instantiated before

as long as you don't write to storage it won't persist it? good to know

you can create DOs with a location hint which will tell it where you want it to be created if it isnt created yet 🤷

Once a DO is created it will always be at the same location even if you dont use storage afaik

IIRC that is the current behaviour, but that might change at some point.

Thank you all for the responses 🙌 I'm not sure about this, at least it's documented anywhere. It looks like first request instantiated the DO and then it can't move (for now).

Yeah, but in that case I can't know which location will be best for the end user.

Looks like a viable solution, but a complex one for such problem. Hopefully Cloudflare will implement an API for this at some point.

not really complex, if you use something like

itty-durable

this is about 8 lines of code total

but yes would be nice to have out-of-the-box

True, also it'll no longer be a problem once Cloudflare implements auto-reallocation of the DO closest to the latest request (it's part of the roadmap according to the docs).

You might be misunderstanding slightly - If it moved every time there was a new request from a different place, that'd be incredibly inefficient

No I understand that part, if the DO is evicted, and then 2 days later there is a new request from a different location, it makes sense to instantiate it closer to this new location. Which is fine in my use-case.

I don't expect the DO to move at every request, or even shortly after being evicted, but knowing that its location is not determined forever is great, because in my case the issue is that the first request might come from our backend, but then most requests will be from end-users at different locations.