I doubt this works. Did you test it? You are modifying a local variable here, not the actual env inj

I doubt this works. Did you test it? You are modifying a local variable here, not the actual env injected into your worker/DO if it happens to be created in a different machine or even a different isolate/process.
If you want data in your DO that are not in the

env

env

, you need to pass them in your RPC call to the DO.

Llambrospetrou I doubt this works. Did you test it? You are modifying a local variable here, no...

atgctg•2/22/25, 1:09 PM

The variable shows up on env, but only tested locally.
Just would have been nice to be able to initialize it in the constructorconstructor, I might make an

init

init

method so I don't have to pass it on every call

Aatgctg The variable shows up on env, but only tested locally. Just would have been nice...

lambrospetrouOP•2/22/25, 1:11 PM

See https://developers.cloudflare.com/reference-architecture/diagrams/storage/durable-object-control-data-plane-pattern/

Cloudflare Docs

Control and data plane architectural pattern for Durable Objects · ...

Durable Objects are built on-top of Cloudflare Workers spanning several locations across our global infrastructure network.
Each Durable Object instance has its own durable storage persisted across requests, in-memory state, single-threaded execution, and can be placed in a specific region.

Llambrospetrou See https://developers.cloudflare.com/reference-architecture/diagrams/storage/du...

atgctg•2/22/25, 1:23 PM

That's a great resource, thanks.
So based on that, I think I should call init(uid)init(uid) the first time the user object is created, save the user's id to storage, and this way it will be available in storage whenever I'm calling that DO again, right? Just need to set it in the constructorconstructor like this:

ctx.blockConcurrencyWhile(async () => {
  this.uid = await ctx.storage.get('uid')
})

ctx.blockConcurrencyWhile(async () => {
  this.uid = await ctx.storage.get('uid')
})

Aatgctg That's a great resource, thanks. So based on that, I think I should call `init(u...

James•2/22/25, 4:11 PM

I’m conservative on rpc calls and to avoid unnecessary round trips, I just pass a metadata obj to all my rpc calls as an optional arg which defaults some helpful initialization stuff to the DO

1984 Ford Laser•2/23/25, 7:32 AM

Anyone know if partysub has a limit on the number of topics that can be specified?

TTyveris Specific questions: 1. Is it ok to pull the websocket property off the internal ...

geg•2/23/25, 5:21 PM

This is how it's done, you're on the right track

TTyveris It seems like it is possible to create a WebSocket connection from a worker to a...

Franco Romano Losada•2/23/25, 6:39 PM

Have you tried PartyServer (https://github.com/threepointone/partyserver/tree/main). You avoid a lot of boilerplate and get some good things too. I was doing it like do but from Hono but this library is nice, and provides a nice client too

chronark•2/24/25, 9:25 AM

anyone else getting a ton of errors right now from durable objects?

- Internal error in Durable Object storage write caused object to be reset.Internal error in Durable Object storage write caused object to be reset.
- Network connection lost.Network connection lost.

1984 Ford Laser•2/24/25, 10:43 AM

Why would this code cause 2 DO read operations when a websocket client connects then immediately disconnects?

11984 Ford Laser Why would this code cause 2 DO read operations when a websocket client connects ...

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

You're checking path but not method I expect

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

I assume that you're trying to connect a WebSocket for the initial OPTIONS preflight and that's causing the extra request

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

Assuming WS sends preflight

IIsaac McFadyen You're checking path but not method I expect

1984 Ford Laser•2/24/25, 11:04 AM

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 Laser•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 Laser•2/24/25, 11:07 AM

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

1984 Ford Laser•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...

lambrospetrouOP•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...

lambrospetrouOP•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...

lambrospetrouOP•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...

lambrospetrouOP•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...

lambrospetrouOP•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

I doubt this works. Did you test it? You are modifying a local variable here, not the actual env inj

Similar Threads

Similar Threads

Similar Threads