Okay this is a dumb one, I think I fixed
Okay this is a dumb one, I think I fixed it. On top of the normal
message and close WS handlers, I also had a error one set up, which was supposed to remove the current connection from the list of connections, but wasn't necessarily closing the connection, such as if the client experienced an error, but not one that caused the socket to close. Somewhere, this was causing the socket to stay open or something. You can see a comparison in the screenshots
6 Replies
This still seems weird? Maybe I don't properly understand the situation, but if your DO wasn't receiving messages the DO should still hibernate. Unless you just mean your DO was trying to do work but wasn't able to because the WS client had gone away
I'm pretty sure its the latter
I'm away for a couple days but when back I can try and put together a repro and see if I can get it to happen again? I've had no issues since I changed some code
Sounds good, I'm actually gonna be out for a bit too, can circle back early Feb 🙂
This note in the docs might be of interest in this issue:
I currently don't do anything on the client-side to respond to server-executed
close(), something in the docs on how to effectively do this would be great. I will repro this at a later date but just wanted to add to this so I don't forgetSorry, didn't get a notification for this. Just a heads up but you might find this useful https://datatracker.ietf.org/doc/html/rfc6455#section-5.5.1
If an endpoint receives a Close frame and did not previously send a Close frame, the endpoint MUST send a Close frame in response. (When sending a Close frame in response, the endpoint typically echos the status code it received.) It SHOULD do so as soon as practical. An endpoint MAY delay sending a Close frame until its current message is sent (for instance, if the majority of a fragmented message is already sent, an endpoint MAY send the remaining fragments before sending a Close frame).
IETF Datatracker
RFC 6455: The WebSocket Protocol
The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by ...
I think our examples (1, 2) show this (if we receive a close we reply with a close back), you'd want to do something similar on the client.
It's always a bit tricky to sufficiently document these things, since this is more of a "how websockets work" kinda thing, less of a "how to use websockets on our platform" kinda thing.