Disconnecting EventSubWebSocket then Connecting again causes exception

[grofit]

As the title says I currently am unable to disconnect the socket at runtime and then reconnect it as if I do I just get the error:

[08:53:22 ERR] Error with Twitch EventSub [System.InvalidOperationException: The WebSocket has already been started.
at System.Net.WebSockets.ClientWebSocket.ConnectAsync(Uri uri, HttpMessageInvoker invoker, CancellationToken cancellationToken)
at TwitchLib.EventSub.Websockets.Client.WebsocketClient.ConnectAsync(Uri url)]

The scenario I have is a GUI app where the user can connect/disconnect from twitch as they please, here is the steps:

@Scenario Should let me disconnect and reconnect to twitch event sub on same socket
Given I have valid twitch auth tokens
And I have already called `ConnectAsync`
And am connected to twitch EventSub
When I call `DisconnectAsync`
And then call `ConnectAsync`
Then it should connect to twitch EventSub

As mentioned above the calls occurring are basically:

// One pathway which is triggered a few ways which runs this
var success = await myEventSubWebSocket.ConnectAsync(new Uri("wss://eventsub.wss.twitch.tv/ws")); // To Connect

// A pathway runs this if the client disconnects/removes their twitch auth
var success = await myEventsubWebSocket.DisconnectAsync(); // To Disconnect

If it helps here are the related logs I can see being spat out from this process:

[08:52:52 INF] Checking to see if twitch EventSub needs connecting
[08:52:52 INF] Connecting to twitch EventSub
[08:52:52 INF] Connected to twitch EventSub
[08:52:53 INF] Attempting to Subscribe to [whatever] for [channel.update]
[08:52:53 INF] Timestamp: 06/13/2024 08:52:53 Type: Request Method: POST Resource: https://api.twitch.tv/helix/eventsub/subscriptions Content: {
"type": "channel.update",
"version": "2",
"condition": {
"broadcaster_user_id": "whatever"
},
"transport": {
"method": "websocket",
"session_id": "whatever"
}
}
[08:52:53 INF] Successfully Subscribed to [whatever] for [channel.update]
[08:52:53 INF] EventSub Channel Update Subscription Successful
[08:53:13 INF] Revoking Twitch Token
[08:53:15 FTL] NormalClosure - client disconnected
[08:53:22 INF] [Twitch OAuth]: Successfully authenticated
[08:53:22 INF] Checking to see if twitch EventSub needs re/connecting
[08:53:22 INF] Connecting to twitch EventSub
[08:53:22 ERR] Error with Twitch EventSub [System.InvalidOperationException: The WebSocket has already been started.
at System.Net.WebSockets.ClientWebSocket.ConnectAsync(Uri uri, HttpMessageInvoker invoker, CancellationToken cancellationToken)
at TwitchLib.EventSub.Websockets.Client.WebsocketClient.ConnectAsync(Uri url)]
[08:53:22 INF] Could not connect to twitch EventSub

Some of that logging is specific to my App but at least this can give you some idea as to the flow of things and whats happening. As some of the logic takes place outside of the TwitchLib functionality, such as the Twitch OAuth process etc, but once that happens it triggers other logic to run.

I think the main thing for me is that it seems to show [08:53:15 FTL] NormalClosure - client disconnected could possibly be raised from TwitchLib.EventSub.Websockets/Client/WebsocketClient.cs which would imply its blowing up internally for some reason.

If you need any further information let me know.

[grofit]

Is this fixed now? I can see movement on merges but on nuget I cant find any recent releases

[WrithemTwine]

Is this always necessary? I just don't understand the need for an infinite time connection.

TwitchLib.EventSub.Websockets/TwitchLib.EventSub.Websockets/EventSubWebsocketClient.cs

Line 457 in 663f3c8

_cts?.Cancel();

It will always cancel the task for disconnecting because _cts is always an instantiated object (_cts?.Cancel(); resolves to valid):

TwitchLib.EventSub.Websockets/TwitchLib.EventSub.Websockets/EventSubWebsocketClient.cs

Line 442 in 663f3c8

_cts = new CancellationTokenSource();

It's deceptive. "DisconnectAsync()"-> but will never disconnect once the websocket client connects.

In my use-case, I have up to 3 EventSubs (based on account access permissions i.e. user can have a bot account for chatting output or use their streamer account, and also any-scope vs no-scope subscriptions must have separate Oauth access tokens=>separate EventSub connections) specific for active streams. I give the user the option to keep the app open and close the eventsub client connection between streams, which can be 2-5-15 days apart; hence, it's not necessary to have an EventSub connection always connected per streamer/user choice.

My now current workaround will be to dereference the EventSub and build a new one, including all the event hookups. The garbage collector should cleanup the old EventSubs.

[AoshiW]

Is this always necessary? (_cts?.Cancel())

Yes, it is. If there were no null check, it is possible that instead of returning false, a NullReferenceException exception would be thrown. (Honestly, the chance of this exception happening is extremely small, but unfortunately, it is not zero.)

It's deceptive. "DisconnectAsync()"-> but will never disconnect once the websocket client connects.

Can I ask why you think DisconnectAsync doesn't work? I just tested it and it worked.
But to be honest, I found one strange behavior that should be fixed (which is probably why you think it doesn't work): if the client disconnects due to an error, the WebsocketDisconnected event is triggered, but if DisconnectAsync is called, the event is not triggered.

[WrithemTwine]

currently using (I thought this issue still existed with these library versions):

I reviewed https://learn.microsoft.com/en-us/dotnet/api/system.threading.cancellationtokensource?view=net-9.0 about Cancellation Token Sources, and first believed "cts.Cancel();" was a return type call (aborts DisconnectAsync() to skip the return). Reviewing further, it's a token to align cancelation across different threads/tasks, in this case it stops
private async Task ConnectionCheckAsync() { while (_cts != null && _websocketClient.IsConnected && !_cts.IsCancellationRequested)

(Yes, I know the "?." is needed as a null check. The null exception will happen when DisconnectAsync() is called before ConnectAsync() is called, because ConnectAsync() constructs _cts and it's no longer null. In libraries, it's possible to throw an exception on DisconnectAsync() called first with "exception, cannot Disconnect, Websocket isn't connected, call ConnectAsync() first". That's a library decision. Client code shouldn't call Disconnect first anyway.)

I received the same as the OP regarding a "Websocket client still connected" exception when trying to call ConnectAsync() again and I posted from a point of frustration, and trying to find something to solve the issue - my bot is now very healthy in operation apart from this EventSub hiccup.

So when using: "ConnectAsync() -> DisconnectAsync() -> ConnectAsync()-'already started' exception", it seemed impossible getting the websocket started again. Also, I use the "Connected" event to subscribe on the connection, per the Twitch "subscribe within 10 seconds or we're not friends anymore" requirement;

....Edit-Removed extra detail....

I have some logging built in with my code (I might need to add a little more detail) and I could find some time in the next few days to run some EventSub operation connect/disconnect operations to document what's observed. I can also verify based on current NuGet versions.

[WrithemTwine]

Ok. Since my bot logs many lines and it might be difficult to understand, I'll summarize here what I found.

My app starts and waits for user to start the EventSub bots.

I click a radio button and the EventSub bots start, receive the WebsocketConnected event, and start adding the subscriptions.

Operations appear normal.

I click a radio button and the EventSub bots stop, receive the WebsocketDisconnected event.

Wait a little bit.

I click a radio button and start the EventSub bots again, receive the WebsocketConnected event. The subscriptions start to add, but stops and don't add to Twitch.

The 10 second delay without subscriptions causes Twitch to disconnect the connection.

Receive the WebsocketDisconnected event. App thinks it's active and tries to reconnect the Websocket. Tries to first stop then restart the EventSub. EventSub throws error (OnError) stating the Websocket can't be started because it is already connected.

---

What I found was, where I track the added subscriptions; once the EventSub disconnects I didn't remove the subscriptions from the manager (tracks what subscriptions got added) so connecting again and the subscriptions are thought to be added but not added again causing Twitch to close the connection.

My error.

Added a "RemoveClearSubscriptions" method to clear out data when user stops EventSub, and a new connection now reliably adds the subscriptions again to keep the Websocket connected.

---

I believe what gets lost in the EventSub operation is:

• every connection -> upon connected add at least 1 subscription.

• disconnect - stop tracking subscriptions, clear them from anything tracking (depends on user code)

• new connection -> upon connected add at least 1 subscription (regardless if already added last time).

• refreshing access token -> clear all the subscriptions and add the subscriptions again with the same Websocket connection, utilizing new access token.

• subscriptions with a scope -> can share same access token

• subscriptions without a scope -> can share same access token

• subscriptions with & without scopes -> can't share same access token

---

Now I'm not sure if this is an actual issue. Missing steps can cause this 'already connected' exception. Not sure if it's prudent to manage within EventSubWebsocket if no subscriptions add and that's why Twitch disconnected the Websocket.
It's also possible (not necessarily good) to over-engineer EventSub.

Thanks for the info. I had to take a harder look and found the issue.