Could it be OOM? Are you just forwarding the data or also storing to memory?

i tried both cases, storing it and purely forwarding it. It happens even when i dont store anything

so not some kind of memory limit issue

someone else also DMd me saying they have the same issue with their project asking me about my experiences too

also the bug fix where old clients are disconnected when there is a version update doesnt fix it

i tried all sorts of stuff. e.g running an exception handler and forwarding the error to another listening websocket

but the error handler didnt even trigger to begin with

the code is really simple and clean so at this point im really sure there are no errors with it

I see, I am not having clients being connected for hours, so I probably didn’t hit the issue yet. But I am more than happy to take a look if you have the code I can replicate it with 🙂

i have code you can replicate it but you kind of have to wait a while for the first instance of the issue to show up

after it shows up the first time itll show up every minute or so

thats why i theorise that it uses up some kind of quota then does that

and if you deploy it to a new worker its like the quota lasts a long time

it took a day for my reproduction to show up the issue

if youre ok with that i can maybe prep it up again and send it over?

Totally fine, I was about to say I would prob take a look later so it can run in background till replicated 🙂

I call my use-case "best-effort" writes, one of the Durable Objects namespaces is used in a way it gets requests quite often, where the memory writes happen on each request. I don't necessarily need to write to storage unless it's decided based on some rules/conditions - this may happen for 1/100 requests. However, the current memory state is nice to have at least somehow persistent as there is some nice to have info about the last requests. I am thinking about writing them to storage on some schedule (e.g. every 5 or 10 minutes) or even randomly to achieve it. Having some kind of not guaranteed scale down/termination notifications would be really great to achieve persistency also between deployments of a new code or migrations between colos in the future. So it's nothing critical, rather than nice to have a feature that would help me not to write to storage more than needed and possibly reduce costs on both sides. I can imagine it might be helpful also while debugging some weird edge-cases, where information about the instance (graceful) termination can be very handy.

What's the memory limit?

afaik same as Workers - 128MB

So this means the state the durable object can store cant exceed 128mb?

Or is that seperate?

you cannot load to memory more than 128MB at once, but you can store/read from storage as much as you want (or as much as you dont reach storage limits)

@User it's quite possible that you're hitting the DO's CPU limit. CPU limiting for long-running websockets is pretty bad right now -- the entire lifetime of the websocket uses the CPU budget from the request that opened the websocket, so it gets 50ms + extra cushion at the startup of the object. We're planning to switch this over to the Workers Unbound model so that websockets won't get randomly disconnected due to running out of CPU

If you want, I can double check whether CPU exceeded errors are what's happening to you if you give me your account ID

Or you may be able to see that for yourself in analytics for the worker in the dashboard

First sight on DO... fun times ahead!!

Is it open beta now as I'm seeing DO tab in my Workers dash?

Ooo I got it too 👀 Hell yes

does it work? i dont feel like paying $5 to find out