it could fire again, but the DO will be busy on its current thread, but if you await anywhere in the

it could fire again, but the DO will be busy on its current thread, but if you await anywhere in the DO, then you're open to losing synch

and if you fire the alarm and offload to a worker, well thats all async and anything goes

JJames it could fire again, but the DO will be busy on its current thread, but if you a...

lambrospetrou•1/23/25, 5:53 PM

That's not how it would work. Each time you set the alarm you schedule one execution. And you setup a new alarm in that invocation, so until you set a new alarm time, there won't be a new alarm invocation.

JamesOP•1/23/25, 6:09 PM

are you sure we're talking about the same thing?

alarm 1 fires, has async tasks and takes 10 seconds with some async sprinkled throughout
during the execution context switching, other things can happen on the DO

I know only one alarm can be set at a time, but in this case the alarm already fired, and its up to the developer to manage the data flow from there, especially if these tasks run async

JJames are you sure we're talking about the same thing? alarm 1 fires, has async tasks...

lambrospetrou•1/23/25, 6:10 PM

For multiple async requests sure, it's the developer, but previous messages were arguing about having two alarm invocations at the same time.

Llambrospetrou For multiple async requests sure, it's the developer, but previous messages were...

JamesOP•1/23/25, 6:14 PM

and they could be running at the "same time" if async and the alarm execution runs past whats expected, my understanding is the alarm can only have one scheduled at a time, but once fired, one could schedule it again inside the same execution, or another execution depending on how the async calls are interleaved

Aalgads OK, let me make sure I understand this. If I set a DO to invoke an alarm, the a...

森

森@VerseLink (RW)•1/23/25, 8:10 PM

You are overthinking it, it's simple, alarm like other functions are simply like a I/O event like fetch, but triggered by Cloudflare's internal system once the time is to invoke the alarm function.

森

森@VerseLink (RW)•1/23/25, 8:12 PM

so it's just like calling multiple fetch, except in this case it's just alarm, and also it automatically retries to call the alarm function just in case it threw an error

森

森@VerseLink (RW)•1/23/25, 8:15 PM

so no, they technically don't get "queued", they just get called whenever the time is up, regardless if any alaram or fetch is being invoked or not; this makes them possible to run concurrently

森

森@VerseLink (RW)•1/23/25, 8:16 PM

so if you really want to have a "queued" up behaviour, you should simply

async alarm() {
  doSomething();
  await this.ctx.storage.setAlarm(); // set the next alarm 
}

async alarm() {
  doSomething();
  await this.ctx.storage.setAlarm(); // set the next alarm 
}

this way the alarm will behave as if they were in queue, and have this nice added bonus that only successful alarm calls will proceed to the next alarm call

森

森@VerseLink (RW)•1/23/25, 8:18 PM

before workflow was a thing, you would implement a queue using DO's KV API, and deque one action out, execute it via alarm, and queue for the next action (pretty sure this is also what is happening underneath the hood, just not in JS land)

peachneo•1/24/25, 7:45 AM

I have this function:

async function exhaustAlarms(stub: DurableObjectStub) {
    let count = 0;
    while (true) {
        let ran = await runDurableObjectAlarm(stub)    
        // await new Promise(resolve => setTimeout(resolve, 100))
        if (!ran) {
            break
        };
        count++;
    }
    return count;
}

async function exhaustAlarms(stub: DurableObjectStub) {
    let count = 0;
    while (true) {
        let ran = await runDurableObjectAlarm(stub)    
        // await new Promise(resolve => setTimeout(resolve, 100))
        if (!ran) {
            break
        };
        count++;
    }
    return count;
}

If I don't add some small delay (see the setTimeout), I get this issue:

workerd/io/worker.c++:2082: info: uncaught exception; source = Uncaught (in promise); stack = Error: Durable Object storage is no longer accessible.

peachneo•1/24/25, 8:03 AM

overall, testing of DOs seems really fragile...I get inconsistent errors, different errors on live reload than hard restart etc

Ppeachneo I have this function: ``` async function exhaustAlarms(stub: DurableObjectStub)...

森

森@VerseLink (RW)•1/24/25, 9:01 AM

What is runDurableObjectAlarm

Ppeachneo overall, testing of DOs seems really fragile...I get inconsistent errors, differ...

森

森@VerseLink (RW)•1/24/25, 9:03 AM

I realized this ago, not fragile, but just the error thrown usually doesn’t align with the actual error

LearnNMake•1/25/25, 2:46 AM

I am researching migrating to a D1 Database. I need one source of truth for the relational data. I will be updating the database with a backend application. The frontend will be performing reads. I need everyone in the world to get the most up to date data. I read that D1 performs replication geographically so this doesn't seem like a good fit. I would rather there be a delay than a client get the wrong or outdated data. Is it possible to somehow force one persistent storage to be used world wide? Are durable objects a solution for this dilemma? Can I enforce everyone in the United States to somehow use one specific D1 Database?

LLearnNMake I am researching migrating to a D1 Database. I need one source of truth for the ...

boop•1/25/25, 8:24 AM

There aren't replicas on D1 yet

LLearnNMake I am researching migrating to a D1 Database. I need one source of truth for the ...

lambrospetrou•1/25/25, 10:39 AM

Can I enforce everyone in the United States to somehow use one specific D1 Database?

This applies both to D1 and DO. If you want to use different databases per region, you can create a few of them, and then use your worker request location (in the request headers) to decide where to route your queries (choosing the database/DO that you want). Needs a bit of code, but doable.

I read that D1 performs replication geographically so this doesn't seem like a good fit. I would rather there be a delay than a client get the wrong or outdated data.

Once D1 launches read replication you will still be able to get the latest data if needed, we will not break the default consistency. This would mean though that all your requests would need to reach the primary database (transparent to your code, we would do this for you probably), so you would basically use D1 as its current form forgoing the replication features.

More on this once it's ready and out though, replication is not released yet, so now any query you make to D1 goes to the same database, hence you always get the latest data.

森

森@VerseLink (RW)•1/25/25, 11:41 AM

is it faster to store a user's durable id (calculated from the user id) in D1, then query D1 to get the DO object faster; or is it faster to just use the user's id to get the DO?

森

森@VerseLink (RW)•1/25/25, 11:42 AM

and it is a good idea the cache the DO's id (store on client via JWT) or just get the DO via the user id everytime instead?

森森@VerseLink (RW)is it faster to store a user's durable id (calculated from the user id) in D1, t...

lambrospetrou•1/25/25, 1:36 PM

Definitely directly to the DO. If you go to D1 first, you are already reaching a remote database, so you might as well go to the DO directly.
Read https://developers.cloudflare.com/reference-architecture/diagrams/storage/durable-object-control-data-plane-pattern/ to get some more insight.

森森@VerseLink (RW)and it is a good idea the cache the DO's id (store on client via JWT) or just ge...

lambrospetrou•1/25/25, 1:38 PM

There shouldn't be a noticeable difference between these once you have regular traffic. Using idFromNameidFromName has one extra hop the first time you query it but then it's cached in cloudflare's datacenters, so assuming you have regular requests, there shoudn't be a performance benefit caching the DO ID yourself.
Always benchmark though, and it always depends on your traffic. Don't optimize prematurely.

森

森@VerseLink (RW)•1/25/25, 1:42 PM

Thank you very much!

Let's say we allow users to look up any user's public metadata (for example /user/{userid}/user/{userid}, would it be better if we first look up D1 to see if the user id exists, or directly get the user's DO via idFromName()idFromName(), and see if it was previously initialized, destroy it (via

deleteAll()

deleteAll()

) if not?

I would of course benchmark this, but would like some pointers.

森森@VerseLink (RW)Thank you very much! Let's say we allow users to look up any user's public meta...

lambrospetrou•1/25/25, 1:50 PM

and see if it was previously initialized, destroy it (via deleteAll()) if not?

Why would you need to delete all if nothing has been initialized?
In this case you need to make your constructor readonly, not writing anything to storage unless needed.
If you do all your table initialization in the constructor, then this won't work nicely.

Anyway, it depends on your usecase. There is a similar discussion a few weeks ago in this group about initialization done in constructor or not for publicly accessible links.

森

森@VerseLink (RW)•1/25/25, 2:19 PM

Got it, looking thru the documentation you provided, I have better understanding of what's happening behind the scene for DO.
Readonly as in it's acceptable to do SELECT * FROM 'tablename'SELECT * FROM 'tablename' and we know the DO is not initialized if the table name doesn't exist? (or querying sqlite_mastersqlite_master to check if table exists)

森森@VerseLink (RW)Got it, looking thru the documentation you provided, I have better understanding...

JamesOP•1/25/25, 4:14 PM

DO object / stub initialization and table initialization are completely independent concepts. The constructor talk is just a convenience some developers take on.

You’ll always get errors querying tables don’t exist until you create them. How you manage migrations including table init is your call.

JamesOP•1/25/25, 4:16 PM

I personally find it computationally wasteful to constantly re-init or look for tables which may or may not be there on init. As in my app lifecycle, I may run millions or billions of requests on a DO between migrations I choose to create.

JJames DO object / stub initialization and table initialization are completely independ...

森

森@VerseLink (RW)•1/25/25, 4:23 PM

yeh i understand they are different concepts, i'm just concerned if i were to invoke any sql commands, it may not be readonly as I imagined

JJames I personally find it computationally wasteful to constantly re-init or look for ...

森

森@VerseLink (RW)•1/25/25, 4:23 PM

so your approach is to have a db lookup first then to invoke a DO?

JamesOP•1/25/25, 5:47 PM

The db is just a set of calls in the DO. You have to be in the DO to access it.

Aalgads When you say after the first hop, its cached in the local datacenter, is it cach...

lambrospetrou•1/26/25, 12:36 PM

There are too many variables in what you describe. How you instantiate DOs, how long that takes, is it serially or paralle, and many other things.
In general, any work you can parallelize from your worker the better. You should not pre-optimize DO stub creation until you actually measure it and see that it's the bottleneck in your code. Performance optimizations just based on intuition doesn't work. Measure and then optimize accordingly.
Start with simple code doing what you need and take it from there.

森森@VerseLink (RW)so your approach is to have a db lookup first then to invoke a DO?

lambrospetrou•1/26/25, 12:39 PM

My mental model for Durable Objects constructor is different than most.
As the step 3 in https://developers.cloudflare.com/reference-architecture/diagrams/storage/durable-object-control-data-plane-pattern/ describes, I prefer doing the expensive DO initialization in a dedicated init()init() call that is part of a resource creation flow. Including any initial SQL table creation and setup. After the init() completes, any other SQL migration is done only when necessary (at the point of access, not the constructor, and it's very fast/noop majority of the time when done properly: https://github.com/lambrospetrou/durable-utils?tab=readme-ov-file#sqlite-schema-migrations ).

I don't consider the constructor to be the place to do expensive initialization. The DO constructor as of today should be fast, and I only use it to initialize the "in-memory state of the DO". Loading anything from the storage into memory if necessary or just not do anything expensive.
It's different from how most folks think about the DO constructor, but in practice this works much better, especially if your DOs are not receiving enough traffic to stay warm and you have many cold starts, so you need to keep your constructor lightweight.

Llambrospetrou My mental model for Durable Objects constructor is different than most. As the s...

森

森@VerseLink (RW)•1/26/25, 2:26 PM

Thanks, yeh, I'm using Drizzle to manage migration of our database structure (just that, still write raw SQL most of the time), and the migration code it provided was less ideal so I had to incorporate your suggestion into it.

I guess premature optimization is evil, but I'm still curious about how I can approach DO init a bit better. I sort of understood how DO creates objects that were previously created (say via idFromName), but I'm still uncertain how DO creates when it's a new name id that it had never seen before. Does it ask every data center if that name id has existed before creating the object? or does it create it first anyways, and only sync at storage level?

If it was the latter, if two people decides to create the same name id DO at the same time on the opposite side of the earth, they would not see the same in memory status as the other? (or is there more memory syncing magic involved)

森森@VerseLink (RW)Thanks, yeh, I'm using Drizzle to manage migration of our database structure (ju...

lambrospetrou•1/27/25, 10:37 AM

Does it ask every data center if that name id has existed before creating the object? or does it create it first anyways, and only sync at storage level?

This is my personal suggestion, but you shouldn't design your applications based on internal implementation.
If DOs internally ask every datacenter, or some of them, or use a central database, should not impact your designs. The end result for you and your application is how long would this process take. So, do that, measure it, and only if it's slow for your use-case start thinking about optimizations. Internal implementations can and will change over time.

If it was the latter, if two people decides to create the same name id DO at the same time on the opposite side of the earth, they would not see the same in memory status as the other? (or is there more memory syncing magic involved)

Read https://developers.cloudflare.com/durable-objects/platform/known-issues/
The uniqueness guarantee is strictly enforced when you access storage.

lemmih•1/27/25, 10:39 AM

Can I emit log messages from a Durable Object?

geg•1/28/25, 8:11 AM

Hi, can it be that runtime updates break hibernated websockets? My DO can still send messages out but incoming messages stop arriving at random times. I noticed that it doesn't happen over the weekends and as soon as the weekend is over it starts happening almost every day, sometimes every couple of hours on a given day. My DO code couldn't be simpler, message in -> message out. I strongly believe it's runtime updates at this point. Reconnecting the "writing" websocket fixes it.

Ggeg Hi, can it be that runtime updates break hibernated websockets? My DO can still ...

lambrospetrou•1/28/25, 8:26 AM

Not sure about this specific issue, but you should be doing reconnection anyway, since servers can go down for many reasons, therefore your clients should attempt to reconnect (with usual jitter+backoff) if the connection fails.

Llambrospetrou Not sure about this specific issue, but you should be doing reconnection anyway,...

geg•1/28/25, 8:29 AM

What I meant with "messages stop arriving" is that there is a connection with no errors, yet messages don't arrive.

geg•1/28/25, 8:31 AM

When this issue happens to me, reconnecting doesn't work instantly also, the websocket connects fine but messages don't arrive still. I have to give it like 10 seconds before reconnecting, then magically it starts working again..

geg•1/28/25, 8:35 AM

When I deploy new code, the websocket disconnects and my "writer/sender" gets a close frame and reconnects fine.

nejc•1/28/25, 8:46 AM

hi all, one thing that I always prevent me from using DO is observability. Each object is isolated via ID, so can I get a whole picutre of what is happening. Let's say that I build a chat app which uses DO and each session ID is it's own DO ID. Now I would like to get real time overview of how many sessions I have and how many users are active. Is there an easy way to do this inside DO, or do I need D1 / Analytics engine in parallel, where DO pushes this data there?

iLearn•1/28/25, 9:25 AM

Pulling this Q out of thread (thread : Creating Replica for a DO), for kind attention and response :

Use-Case :
I have DO per user, accessed through unique_id (= email of user).
Now, a user requests to change email.
Hence, need to "replicate" complete DO(old_email) to DO(new_email)

My Q :
Q#1 : Is my request to "replicate" feasible ?
Q#2 : If yes, how to achieve this ? (a sample code will help)

Thanks.

IiLearn Pulling this Q out of thread (thread : Creating Replica for a DO), for kind atte...

lambrospetrou•1/28/25, 10:14 AM

There is no built in method now to duplicate the storage of a DO to a different one. You need to do the copy of the data in your code. Reading rows/KV items and writing them in the new one.

In my opinion though, if users are meant to be able to change their emails in your application, then those emails are not a good key to use for your DOs. The DO keys should be immutable identifiers for the data hosted in that DO. Otherwise it will become very expensive and slow to duplicate DOs all the time, and unless you block access to them while that's done you will also have consistency issues.

Ggeg What I meant with "messages stop arriving" is that there is a connection with no...

1984 Ford Laser•1/28/25, 12:17 PM

Are you broadcasting the message to all connected clients, or only the one that sent the message to the server?

1984 Ford Laser•1/28/25, 12:23 PM

If you're sending it directly, I'd be curious to see if the wsws can be found in the this.state.getWebSockets()this.state.getWebSockets() set

11984 Ford Laser Are you broadcasting the message to all connected clients, or only the one that ...

geg•1/28/25, 12:25 PM

webSocketMessage(source: WebSocket, data: string) {
  for (let ws of this.ctx.getWebSockets()) {
    if (ws == source) {
      continue
    }
    
    ws.send(data)
  }
}

webSocketMessage(source: WebSocket, data: string) {
  for (let ws of this.ctx.getWebSockets()) {
    if (ws == source) {
      continue
    }
    
    ws.send(data)
  }
}

Just like this

Llambrospetrou Of course! https://developers.cloudflare.com/durable-objects/api/storage-api/#tr...

Burrito•1/28/25, 12:35 PM

So if transactiontransaction can be used over transactionSynctransactionSync even in SQLite DO, does that mean the purpose of transactionSynctransactionSync is merely to provide a sync API?

Burrito•1/28/25, 12:38 PM

Cool.

Burrito•1/28/25, 12:40 PM

It'd be nice if the KV API also had sync equivalents in SQLite DO.

it could fire again, but the DO will be busy on its current thread, but if you await anywhere in the

Similar Threads