You mean the Canceled event?

or any http request, but typically ones related to a websocket get logged once the websocket disconnects

or when we release the http req handler

Yeah it works as expected

but you will not see the console.log

> Hibernation does not persist WebSocket connections across code updates. If an event occurs for a hibernated Durable Object’s corresponding handler method, it will return to memory. This will call the Durable Object’s constructor, so it is best to minimize work in the constructor when using WebSocket hibernation. What exactly does this mean? Are these two seperate things (DO will not persist across code updates, oh also constructor will be re-called on each message) or the same thing (if it is evicted because of code update, constructor will be re-called?)

it means if you push a code change the websockets disconnect

If that's what it means it is worded very badly imo 😅 At first it does seem like that but then it says that it will call the constructor so like

No, I'd redesign so that OOM errors were less likely. I don't want the runtime API to react on the fly. Just to observe while exploring different designed. The answers you gave give me that. Thanks. 🙂

two entirely separate things, it's just a paragraph of caveats - 1. hibernation doesn't survive code updates. 2. don't do a bunch of work in the constructor. Would it be any clearer if the code updates was at the end of the paragraph?

I think just rewording it is best something like: When code updates all websockets connected to hibernation are terminated. When an event occurs during hibernation the object will be woken up and will call the constructor, so it is best to minimize work in the constructor when using hibernation.

it's not any event during hibernation, it's events corresponding to handler methods that have to run user provided JS - pings wont wake it up, very shortly a new feature will mean particular messages wont wake it up, etc

Ah ok moving the code updates to the end will probably do the trick reads better to have that last

Yeah then a reword might make sense. I understand them both taken separately, just when they're grouped/worded like that it made me assume the first part was related to the second

just two separate paragraphs then

Yeah that would work well, or even a list or something.

I'm curious - how will that be done? The "certain messages" part I mean

Sounds like a great feature

you define a string to match against incoming messages, and a string to respond to it with. that way you can do application-level pings without waking it up

clearer? https://github.com/cloudflare/cloudflare-docs/pull/9106/files

pr for the auto-response feature is here if you want to get a sense for how it works https://github.com/cloudflare/workerd/pull/456/files#diff-1aef30ef23f565dda5c39ed0f5cb7ba0ed2c2573914386c29d0ae4dbba199227R389

difference between

idFromName

and

idFromString

?

idFromName = using anything you want as an id idFromString = a hex durable object id (can generate one with newUniqueId)

after coming back to my worker after a few minutes; running locally i run into this:

do/node_modules/wrangler/wrangler-dist/cli.js:30488
            throw a;
            ^

Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
Emitted 'error' event on ClientHttp2Stream instance at:
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -54,
  code: 'ECONNRESET',
  syscall: 'read'
}

Node.js v18.12.0

is it because the DO is gone or what?

is there anyway to store all the stubs (object instantiations)? like if i have a DO thats a "chatroom" and i want to keep track of all the chat rooms is there a way to do that within the worker itself

or should i use something like workers kv to handle that?

https://developers.cloudflare.com/api/operations/durable-objects-namespace-list-objects it seems like one way is to call the cloudflare api itself 🤢. not the cleanest solution but the only other thing i can think of is having a KV to store "rooms"

Oh it's because I wasn't hitting the DO, i get logs if I use the DO, didn't realize we migrated off already XD

Happens

don't just store stubs in memory without being aware you need to reconnect them: https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#object-stubs If you're talking about permanently storing names or ids for related DOs, yeah your reasonable options there are KV or another DO. Don't call the rest api on every incoming user request.