Dangling EventSub WebSocket Subscriptions

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.

Hi @RealityRipple, the engineering team is aware of your post and is curious to gather more information to identify any issues.

Can you confirm that your connection URL is the latest version and not the beta version? It should be set to wss://eventsub.wss.twitch.tv/ws.

And do you have approximate days and times you were experiencing issues to help the team debug further? That would be much appreciated if possible.

Yes, definitely not using the beta version.

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:

ID: AgoQ4xh-_627S7iQvBF15M9iYBIGY2VsbC1i
Created: 1687391053 (Wed Jun 21 2023 23:44:13 GMT+0000)
Dangling for: 492s


Created: 1687395363 (Thu Jun 22 2023 00:56:03 GMT+0000)
Dangling for: 1149s

The dangling time is the time between the last received WebSocket message and the time the subscriptions were forcefully cleared, despite their state.

I will add more as more are detected.

Two more today:

ID: AgoQZmJkq6g6Q6awVnTF3_VqlhIGY2VsbC1i
Created: 1687481081 (Fri Jun 23 2023 00:44:41 GMT+0000)
Dangling for: 71s


ID: AgoQ86RoMd-ZQn6BRPoKeYuCUhIGY2VsbC1i
Created: 1687481138 (Fri Jun 23 2023 00:45:38 GMT+0000)
Dangling for: 52s

Thanks for that info. We are looking into this.

A few more in case you need em; these stayed open for quite a while:

Created: 1687604165 (Sat Jun 24 2023 10:56:05 GMT+0000)
Dangling for: 63011s (17 and a half hours)

ID: AgoQzT1EQdEpTBe2SBw2pgd5HxIGY2VsbC1h
Created: 1687844524 (Tue Jun 27 2023 05:42:04 GMT+0000)
Dangling for: 8524s

IDK if the previous creation times all being around midnight GMT were just a coincidence. Seemed like a pattern until these.

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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.