You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tried several times (validating with "!command" type calls to channel and getting 'sendchatmessage' responses), sometimes can last 20+ minutes connected to channel, or within 2-3 minutes receive:
The authcode access tokens have checks and refresh as needed. In this case, the access tokens are already refreshed and would/should be ok for hours.
(still working on reliable logging for more information, have captured "failed ping pong" though)
The text was updated successfully, but these errors were encountered:
Interesting.
What you experienced, the low level ping/pong failing (Code 4002) would be handled outside of TwitchLib inside the .NET Websocket implementation tho so I dont know if this is sth we can help with but rather an intermittend connection issue on your end to AWS.
I missed this part of the documentation about subscription access: https://dev.twitch.tv/docs/eventsub/manage-subscriptions/
"The Subscription Types topic lists the scope requirement for each event. If the event doesn’t specify a scope requirement, you must create a user access token with no scope."
Found out, I mixed scope/no scope subscriptions together and Twitch doesn't like that. so I'll be separating subscriptions into another eventsub instance.
Using 'auth code' access tokens w/access scopes; get access token.
Start EventSub 'startasync' and subsequent Helix "create ChatMessageReceived subscription" after 'OnConnected'.
I'm using the EventSubWebSocket(ILoggerFactory) constructor,
TwitchLib.EventSub.Websockets/TwitchLib.EventSub.Websockets/EventSubWebsocketClient.cs
Line 318 in bd20f9d
Tried several times (validating with "!command" type calls to channel and getting 'sendchatmessage' responses), sometimes can last 20+ minutes connected to channel, or within 2-3 minutes receive:
The authcode access tokens have checks and refresh as needed. In this case, the access tokens are already refreshed and would/should be ok for hours.
(still working on reliable logging for more information, have captured "failed ping pong" though)
The text was updated successfully, but these errors were encountered: