[Bug]: Session disconnection

[josago97]

Check The Docs

• [X] I double checked the docs and couldn't find any useful information.

Verify Issue Source

• [X] I verified the issue was caused by Discord.Net.

Check your intents

• [X] I double checked that I have the required intents.

Description

After updating the library to version 3.13.1 the bot disconnects more frequently. I have been testing and when it connects to a voice channel, it disconnects after about 5 - 10 minutes. I'm back to version 3.13.0 and the connection stays much longer.

Version

3.13.1

Working Version

3.13.0

Logs

Session disconnected

Sample

No response

Packages

Discord.Net 3.13.1

Environment

Windows 10 Pro 22H2 .NET 7

[Misha-133]

We haven't introduced any changes to the voice implementation since 3.13.0

[josago97]

And in the connection system or the one that is responsible for keeping the session active?

[Misha-133]

Nothing You can look at the changelog, no changes have been made to those systems

[Platapoop]

I've had this issue with 3.13.0 too. Before discord required the heartbeat thing, I had rarely any disconnects. This must have been at least a few months now. I wish I had more info, but for now, this is the best stacktrace/information I can get.

I've double checked and it is not due to my cancellation token. I used a dummy one and still encountered the issue.

Here are my relevant logs. Ignore the ERR in front of the logs, I'm pretty sure I wrote all the info as errors. [22:24:20 ERR] Discord: Discord.Net v3.13.1 (API v10) [22:24:20 ERR] Gateway: Connecting [22:24:21 ERR] Gateway: You're using the GuildScheduledEvents gateway intent without listening to any events related to that intent, consider removing the intent from your config. [22:24:21 ERR] Gateway: You're using the GuildInvites gateway intent without listening to any events related to that intent, consider removing the intent from your config. [22:24:21 ERR] Gateway: Connected [22:24:22 ERR] Gateway: Ready

[22:24:25 ERR] Audio #1: Connecting [22:24:25 ERR] Audio #1: Unknown OpCode (18) [22:24:25 ERR] Audio #1: Unknown OpCode (20) [22:24:25 ERR] Audio #1: Connected

[22:29:00 ERR] Audio #1: Unknown OpCode (18) [22:29:00 ERR] Audio #1: Unknown OpCode (20)

[22:42:11 ERR] Audio #1: [22:42:24 ERR] Audio #1: Disconnecting

(WRITTEN BY MY PROGRAM) [22:42:24 ERR] The operation was canceled. at System.Threading.CancellationToken.ThrowOperationCanceledException() at System.Threading.SemaphoreSlim.WaitUntilCountOrTimeoutAsync(TaskNode asyncWaiter, Int32 millisecondsTimeout, CancellationToken cancellationToken) at Discord.Audio.Streams.BufferedWriteStream.WriteAsync(Byte[] data, Int32 offset, Int32 count, CancellationToken cancelToken) at Discord.Audio.Streams.OpusEncodeStream.WriteAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancelToken) at System.IO.Stream.<CopyToAsync>g__Core|29_0(Stream source, Stream destination, Int32 bufferSize, CancellationToken cancellationToken) at System.IO.Strategies.BufferedFileStreamStrategy.CopyToAsyncCore(Stream destination, Int32 bufferSize, CancellationToken cancellationToken) at NCMBot.AudioService.SendAudioAsync(IGuild guild, Byte[] song, CancellationToken ct) in C:\Users\kevin\source\repos\NCMBot\NCMBot\AudioService.cs:line 129

[Platapoop]

The close was from here: From DefaultWebSocketClient.cs if (socketResult.MessageType == WebSocketMessageType.Close) throw new WebSocketClosedException((int)socketResult.CloseStatus, socketResult.CloseStatusDescription);

Looking earlier, it seems like it got a message case GatewayOpCode.Reconnect: { await _gatewayLogger.DebugAsync("Received Reconnect").ConfigureAwait(false); _connection.Error(new GatewayReconnectException("Server requested a reconnect")); } Maybe since I'm still sending data when the opcode to reconnect comes in, discord instantly boots the bot from the server? And that somehow prevents the bot from reconnecting again? Or maybe since after catching the exception (I don't know if it's intended for the library to throw the exception), I almost immediately call CreatePCMStream and it doesn't like it? Or it requires re-authentication and since it's sending data, it errors out? I'll see if I can dig deeper.

Update: I have just had another reconnect attempt after running it a while and it succeeded so above could be a red herring.