[Bug]: Session disconnection about discord.net

[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.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.