> dont call the rest api on every incoming user request understood ill probably do something to a kv store at the moment i am just doing env..idFromName() on every request to update state and that DO class does getting/setting from the transactional storage api

is anyone else using itty-durable and getting an issue with alarms where it'll wait an interval double that you give it then right after do another alarm for the correct interval?

double checked that setting the alarm happens a single time each iteration within the alarm

printing out the timestamp that should occur and the ones that actually do to verify

hibernation isn't working with local wrangler yet, I'll add a caveat to the docs

Okay, thanks. Works well deployed though, so we will just use a development branch for now

wrangler dev --remote

should work though

It does, but the last time I tried, the socket got closed after hibernating and could not wake up without the client reconnection

That does not happen on a deployed worker/do

are websockets and durableobject storage connected 1:1? Id like to connect to a websocket but retrieve storage from different chats. `export class ChatRoom implements DurableObject { storage: DurableObjectStorage env: any sessions: WebSocketSession[] lastTimestamp: number db: any constructor(controller: DurableObjectState, env: any) { //

controller.storage

provides access to our durable storage. It provides a simple KV // get()/put() interface. this.storage = controller.storage`

yeah, I see what you're saying, someone on the team is looking into it but realistically next week at the earliest

Sounds good

storage is related to the given instance of the durable object. It is unrelated to particular websockets.

if you want a given DO instance to get something from a different DO's storage, you'll need to send it a fetch request

can you elaborate on this please? sending a different fetch request meaning call

return chatroomObject.fetch(newUrl, request)

again? because this would establish a new websocket connection.

Completely unrelated to websockets, I am saying that if DO 1 does storage.put(k1, v1) and DO 2 does storage.put(k2, v2), and you want to read k2 from DO 1 , it will need to send a fetch request to DO 2; it cant read that storage directly. That fetch request may set up a websocket, it may not.

we're not trying to call DOs from different DOs. We're trying to create a single websocket connection. and swap between chats without disconnecting and reconnecting websockets. So we're trying to figure out how to get this.storage.list of a specific chat during a websocket event if calling a DO2 from DO1 is a method to retrieve storages from different DOs. we can try to implement that. note: we're using the DO chat sample project.

each chat room in that example is a separate DO instance, potentially running on different machines in different datacenters. you're not going to be able to move a single websocket connection from one to the other without disconnecting.

you could open up multiple websocket connections, one to each chatroom / DO instance you're interested in

On a completely different note, this is my last day at Cloudflare. Appreciate y'alls feedback and best of luck with your projects on Durable Objects.

I promise your question didn't make me ragequit 😉

Good luck with whatever you go on to do!

HAHA. sorry to hear that. any dev team is lucky to have you.

You will be missed gl to you!

Hello, I'm trying to use the environments feature of wrangler for the first time and I am a bit confused as to why durable_objects bindings are not inherited (https://developers.cloudflare.com/workers/wrangler/configuration/#non-inheritable-keys), but durable object migrations are inherited "The migration list is an ordered array of tables, specified as a top-level key in your wrangler.toml file. The migration list is inherited by all environments and cannot be overridden by a specific environment." (https://developers.cloudflare.com/workers/learning/using-durable-objects#durable-object-migrations-in-wranglertoml).

Does the cache API called inside a DO (if its even possible) always pointing to the same datacenter to create a free and eventually consistent cache ?

Yes, you can call cache API inside a DO and will point to the "cache" from that particular colo; And is pretty consistent, you can write read again immediately on the next request that will works very nice as expected for for almost anything on the CDN side that also does a pretty good job on avoid call multiple times the proxied server.

nice, i would just pay for 2 requests instead of 2 + 1 read

most of the times

The rules will be the same as the CDN... Will keep the data until needs to delete for whatever reason.