Cloudflare Developers•11mo ago

The path check is in the Worker not the DO

11984 Ford Laser The path check is in the Worker not the DO

Isaac McFadyen•2/24/25, 11:05 AM

Yeah but if it's an OPTIONS preflight the DO will still be spawned because of the get() and fetch()

Isaac McFadyen•2/24/25, 11:05 AM

From the Worker

1984 Ford LaserOP•2/24/25, 11:06 AM

Im connecting using Postman, haven't noticed any OPTIONS requests in the real time logs

Isaac McFadyen•2/24/25, 11:07 AM

Hmmm OK maybe not that then

1984 Ford LaserOP•2/24/25, 11:07 AM

I also respond to options preflight earlier in the worker prior to pulling a stub

1984 Ford LaserOP•2/24/25, 11:10 AM

Also shouldn't a DO read operation only happen when accessing storage, not pulling the stub itself?

11984 Ford Laser Also shouldn't a DO read operation only happen when accessing storage, not pulli...

lambrospetrou•2/24/25, 12:58 PM

Yes, just getting the stub and going into the DO doesn't cause any storage operation.
From the snippet you shared, I am not sure if acceptWebSocket()acceptWebSocket() does any storage operation, like reading something and updating it with the new socket, since it needs to somehow persist that.

Llambrospetrou Yes, just getting the stub and going into the DO doesn't cause any storage opera...

Milan•2/24/25, 1:44 PM

acceptWebSocket()acceptWebSocket() doesn't do any storage operations (see hibernation-manager.c++).

GitHub

workerd/src/workerd/io/hibernation-manager.c++ at 2f7d61d69f5066836...

The JavaScript / Wasm runtime that powers Cloudflare Workers - cloudflare/workerd

cloudkite•2/24/25, 7:35 PM

Is there any documentation/guidance around what happens when you update your DO script. Found https://community.cloudflare.com/t/durable-objects-state-during-lifecycle-events/319932/5 does that same restriction apply when using this.ctx.storage.sql?

cloudkite•2/24/25, 7:38 PM

Would be great if ongoing requests are given chance to complete, rather than throwing error when storage API is accessed, as this will cause breakages in our usecase.

Unsmart•2/24/25, 8:12 PM

That message still applies. Durable objects are supposed to only have one instance so when code is updated it gets a new instance and the storage is moved to the new instance and no longer accessible by the old instance otherwise it can break things in unexpected ways.

cloudkite•2/24/25, 8:32 PM

That’s a shame, in the case of SQLite where you control the schema with migrations, i feel like allowing storage ops for inflight requests has much less potential to break things unexpectedly than throwing an error

cloudkite•2/24/25, 8:39 PM

Also the majority of code updates might not have any changes to the schema

Ccloudkite That’s a shame, in the case of SQLite where you control the schema with migratio...

lambrospetrou•2/24/25, 9:20 PM

If you run your queries within transactions (implicit or explicit) then nothing should be broken.

Ashley•2/24/25, 11:59 PM

I haven't tried this outside of local, but based on the documentation I was expecting this.ctx.id.namethis.ctx.id.name to return me the string used when calling const stub = env.MY_DO.idFromName('foo')const stub = env.MY_DO.idFromName('foo') - it works fine if I try it on the stub (e.g. stub.namestub.name), but it doesn't work inside the DO itself if I try this.ctx.id.namethis.ctx.id.name - it's undefined. The ID itself is there, but considering the type is of DurableObjectIdDurableObjectId I expected to be able to get the name too - is this not the case?

AAshley I haven't tried this outside of local, but based on the documentation I was expe...

Unsmart•2/25/25, 12:04 AM

No you cannot get the name from inside the DO. You would need to pass the name through and save to storage

Ashley•2/25/25, 12:07 AM

Guessing there is a technical reason why it's not populated? As on the face of it, it is quite annoying it's not populated and (unless I missed it) the docs aren't explicit that it won't be set, and I sort of hoped it would be based on the type

Unsmart•2/25/25, 12:10 AM

The name gets hashed into an id so the DO doesnt know what the name was it only knows the id

Ashley•2/25/25, 12:14 AM

Yeah I get that, I am curious what the point of having

name

name

available on there at all is really considering it can only be called right after you retrieved a DO with said string

(but it's also very late so maybe my tired brain isn't seeing something)

Walshy•2/25/25, 12:34 AM

https://github.com/cloudflare/workerd/issues/2240

Llambrospetrou If you run your queries within transactions (implicit or explicit) then nothing ...

cloudkite•2/25/25, 12:54 AM

I need to run async things like vectorize, openai interleaved with sql queries though? transactions only work if its all sync right?

Iggy•2/25/25, 3:19 AM

Is the 50GB SQLite storage per account a hard limit or soft? If it’s soft, what range would enterprise expect to be able to get to?

HowlOftheSun•2/25/25, 4:25 AM

If I use a decorator on a function in a do would the decorator be able to write to storage in the do? Would I have to pass the ctx?

Ccloudkite I need to run async things like vectorize, openai interleaved with sql queries t...

lambrospetrou•2/25/25, 8:04 AM

I don't follow. Why would you be doing SQL data migrations while you invoke remote APIs? You can do async transactions too, BTW, but it's going to be horribly slow if you mix many migrations with remote APIs.
Anyway, depends what you are doing, but there are async transactions: https://developers.cloudflare.com/durable-objects/api/storage-api/#transaction

Llambrospetrou I don't follow. Why would you be doing SQL data migrations while you invoke remo...

cloudkite•2/25/25, 8:18 AM

Sorry meant that doing inserts from results of remote API

cloudkite•2/25/25, 8:21 AM

So let’s assume I wrap everything in transaction, if a code deploy happens, error is thrown and everything rolls back. So now I need to retry? How do I do that since this is all happening in the websocketmessage handler?

cloudkite•2/25/25, 8:22 AM

client may have left/disconnect, but I still need that state to be recorded

Ccloudkite So let’s assume I wrap everything in transaction, if a code deploy happens, erro...

lambrospetrou•2/25/25, 8:40 AM

This is as any other database really. Ideally, you should not be doing remote calls within your transactions, since it slows down everything. Do your remote call to fetch something, and then start a transaction to do your writes. If the server crashes the writes won't be partially done.

How is this use-case different than any traditional application running on a server and crashing in the middle of your transaction? The database transactions only guarantee consistency within the database, not with the remote calls you make, so retries and all that depends entirely on what the application is doing.

We cannot blindly retry database queries for you since we don't know if it's safe to do so. You are the one knowing that.

Llambrospetrou This is as any other database really. Ideally, you should not be doing remote ca...

cloudkite•2/25/25, 8:56 AM

That’s not really what I was asking. How can I retry since calling any storage call inside the stale DO will error? If I was calling worker -> DO then I presumably would recreate stub and call RPC method or fetch again. However I’m calling websocket -> DO

Ccloudkite That’s not really what I was asking. How can I retry since calling any storage c...

lambrospetrou•2/25/25, 9:07 AM

If the DO crashes/stops running, your websocket will close, so your client needs to reconnect anyway.

Llambrospetrou If the DO crashes/stops running, your websocket will close, so your client needs...

cloudkite•2/25/25, 9:08 AM

Yeh but they may have left/exited in meantime and I still need that state to be saved

cloudkite•2/25/25, 9:16 AM

I wouldn’t have this problem if I use D1/Postgres etc though right? since if I deploy a new version of the DO then the stale DO with inflight request won’t throw error on call to D1/postgres?

WWalshy <https://github.com/cloudflare/workerd/issues/2240>

Ashley•2/25/25, 10:14 AM

Thank you, glad it wasn’t just me!

Ccloudkite Yeh but they may have left/exited in meantime and I still need that state to be ...

James•2/25/25, 3:48 PM

system design should always consider recoverability from network failures regardless of initiator, even if you ran managed postgres on the same machine in some other VPS and the db craps out due to some memory error, your client will need to know how to handle the error and possibly retry the transaction

JJames system design should always consider recoverability from network failures regard...

cloudkite•2/25/25, 5:02 PM

You’re missing the point. Yes I can if it’s a normal error. But not if it’s an error due to stale DO

Ccloudkite You’re missing the point. Yes I can if it’s a normal error. But not if it’s an e...

James•2/25/25, 5:03 PM

maybe im missing something, but doesnt the client get thrown an error regardless of the condition, such as stale DO?

JJames maybe im missing something, but doesnt the client get thrown an error regardless...

cloudkite•2/25/25, 5:05 PM

I can’t rely on client to retry as they may have left/disconnected. if normal error is thrown can retry in the DO

James•2/25/25, 5:07 PM

so you're saying the same code update kills both the client and DO and you're left with the front-end as the final point of recoverability?

cloudkite•2/25/25, 5:08 PM

No saying that can’t rely on client to retry as they may have close browser. If they still there can reconnect and retry. But no guarantee that they are still around

James•2/25/25, 5:12 PM

I don't see this as any different than other types of transactional processing and edge case mgmt. There's a reason half the ecommerce sites up there have a big banner saying 'dont close or refresh this page or else!'. Somewhere along the line we as system designed have to design around failure or data inconsistency, regardless where in the network it happens.

I agree it could be better, but I don't think it's too unusual. If I were concerned about this on my app, i'd probably just try to isolate critical transaction paths to recoverable workflows.

cloudkite•2/25/25, 5:17 PM

By definition it’s unusual because if you used different DB like D1/postgres you wouldn’t have this specific issue

Ccloudkite By definition it’s unusual because if you used different DB like D1/postgres you...

James•2/25/25, 5:19 PM

tradeoffs... your postgres can die for all kinds of reasons

also D1 is no different than DO in that regard, just happens to not be tied to your code base, but then again you could just use DO storage in a different binding to de-couple your websocket handler from storage similar to the D1 or postgres architecture

Ccloudkite By definition it’s unusual because if you used different DB like D1/postgres you...

lambrospetrou•2/25/25, 10:55 PM

You keep mentioning D1/Postgres, but it's not the same. In the scenario you bring up you mention webscockets where the client disconnected but you want the last updates they sent to be persisted guaranteed. Other databases, including D1/Postgres do not guarantee this at all.
Firstly, if the client disconnects, most probably at some point the connection will close too, regardless if the websocket server dies or not. If the client disconnected before their updates were acknowledged, then they are not guaranteed to be persisted and processed. This is not DO specific, it's general systems.

In general, if the client does not wait for ACK, then nothing is guaranteed. No matter the system. Unless you put the update in a queue and process it asynchronously in the background in the server.

Llambrospetrou You keep mentioning D1/Postgres, but it's not the same. In the scenario you brin...

cloudkite•2/26/25, 12:13 AM

I think the confusion is that I’m talking specifically about stale DO from a code update scenario inserting into this.ctx.storage.sql where as it seems you are talking about general errors/disconnects which I do have covered

cloudkite•2/26/25, 12:28 AM

I really just wanted to know if what the cloudflare team member suggested (https://community.cloudflare.com/t/durable-objects-state-during-lifecycle-events/319932/4) was ever implemented:

"I could imagine some users would rather old requests have a chance to complete (including storage operations), and new ones would have to wait on the old object to complete work before they began processing."

sounds like it hasnt, so that answers my question, happy to put this to bed.

King Kazu•2/26/25, 5:47 AM

since dos are single threaded, is it recommended to run AI functions inside a do or should it be done from inside a worker then push updates to the do datastore?

KKing Kazu since dos are single threaded, is it recommended to run AI functions inside a do...

1984 Ford LaserOP•2/26/25, 7:38 AM

Run in Worker 100%

Nimesh•2/26/25, 2:41 PM

Hi, I asked a question in #workers-ai but think it might be more appropriate to share here. I checked the source code of the new agents-sdkagents-sdk (congrulations on the launch) and it looks like it’s based on Durable Objects and one of the examples makes a fetch request to an AI provider, but aren’t Durable Objects charged based on wall time? I was curious if it makes sense to make these these long running AI requests from a DO from a pricing point of view. Is this expected to change anytime soon?

KKing Kazu since dos are single threaded, is it recommended to run AI functions inside a do...

James•2/26/25, 4:23 PM

you pay for wall time on a DO, so yeah like he said, use a worker for API calls

Super Morris•2/26/25, 7:32 PM

I have one very important question:

We tried to use DO+SQLite and built a test worker. Ever first request from around the world is about ~1 second. then its very fast ~60ms. after a minute or so its back to 1 second.

We will have a lot instances for each users app and having "coldstarts" of 1s for every DO instance for every worker location is very very bad for us.... Is there any workaround/setting ?

Please help :NotLikeThis:

The path check is in the Worker not the DO

Similar Threads

Similar Threads

Similar Threads