(there are some bugs currently with

wrangler tail

and durable objects, but I believe it'll properly report the reason for an object reset)

also if you have an outstanding

fetch()

call to the object at the time of reset, then an exception will be thrown on the caller side explaining the problem... but the

fetch()

call has to be still awaiting response headers for this to work, if it has already established a stream or a WebSocket, then there's nowhere to throw the exception unfortunately, so then you just see a disconnect.

but what you could do to debug is have a URL that hangs (on the DO side) when you

fetch()

it (like it could just do

await new Promise()

)... and then you could curl that, and when your object resets, you should get an exception

Ok thanks I'll keep an eye on wrangler tail, for some reason this isn't happening for me now! Very hard to reproduce 😦

yeah cpu/memory limit errors can be like that. 😕

Hmm now it occurred and wrangler tail didnt show anything new

Just the last successful call

Is there a way for the DO to know the current memory it's using

I think this might be an issue on my end, where the websocket connection is not closing properly. When I exit a room I call websocket.close() on the client-side, but it stays in closing for about 1-2 minutes until it finally is closed. Any clue why it's staying so long in a closing state?

the 'close' event is called immediately on the server-side (DO)

but it feels like the worker is still holding the connection

ahh.. interesting, if I call websocket.close on the DO side inside the close event, it closes on the client-side as well

What's the limit you guys found for active connections on DO's?

In terms of WebSockets

I just ran a test using K6, I found that I could technically run:

do_clients............: avg=12532.232088 min=1699    med=12518  max=22793 p(90)=20942 p(95)=22081.65
gateway_clients.......: avg=1.528421     min=1       med=2      max=2     p(90)=2     p(95)=2

But getting timeouts at around 10K but I can 'force' through that to get to +-22K. Which is interesting. The workers hold 2 clients at the most. This is me running 30K connections through it in a span of 2 minutes. Which means that realistically it could hold 1.5*10K? Since I can re-use connections on the worker on average 1.5 times. 🤔

I think the WebSocket

close()

method only closes the socket in one direction (the sending direction). Both sides need to call

close()

to completely close the socket.

Yeah, just a little confusing. If I had properly removed the event listeners from my old socket then I would never have caught this issue.

A little confusing because the close event is called in the DO, so I assumed it was closed both ways

FWIW "close" is actually a type of message in the WebSocket protocol. So the

close()

method actually sends a close message, and the

"close"

event tells you the message was received... these aren't actually telling you that the underling network socket is closed. They should probably have used a different name for that message...

Mmm gotcha, thanks for that clarification!

P.s. my code is based on the chat demo, perhaps adding it there would help others 🙂

you can even send some content in the message, like

ws.close(4321, "Hello")

, and then on the receiving end

event.code

will be

4321

and

event.reason

will be

"Hello"

Neat 🙂

Anyone wanna try my online pictionary? https://skissan.com/room/english1

a pure CF Pages, Workers, KV and Durable Objects solution 🙂

the prototype is roughly ready

pretty neat!

really cool

Thanks!