It appears that the system for detecting websocket_disconnected or websocket_failed_ping_pong states for WebSocket EventSub connections is… lacking. My project’s users are repeatedly running into issues where a dropped connection is not correctly triggering a state change for that socket’s Subscription. I’ve reproduced it myself multiple times just by unplugging my local network cable from my desktop.
If the connection isn’t properly closed, there seems to be an indeterminate chance that the socket status will remain in an enabled state despite no pings or pongs being exchanged for hours, or even days. This results in the 3-connection maximum being reached unexpectedly quickly in the case of small internet hiccups and outages. I had to add a “Force Clear” button to the warning about the maximum EventSub connections because of how frequently leftover Subscriptions would fill the limit, which is very inconvenient to my users.
Please add some better checks to this system, or add a “last ping received” timestamp so we can do it ourselves - unlike the WebHook system, WebSockets are usually over much less stable, customer grade connections.
I put together a system on my own server to keep track of the last ping received from EventSub websockets and report any that are considered “dangling”. So far, the two that have been reported are:
Problem solved-ish. The EventSub-over-WebSocket system relies on the low-level protocol’s ping/pong, rather than any software-level client-side communication. And of course, if a socket in JS is not completely closed and the variable reference to it gets overwritten before it does, the connection is left dangling, but the browser keeps on PONG-ing silently in the background for as long as the page is open.