Restricted VC causes the bot to hang

[solaluset]

Summary

Bot hangs when trying to connect to restricted VC

Reproduction Steps

1. Create a VC
2. Forbid the bot to connect to it
3. Run the connect command

Minimal Reproducible Code

import os

import discord


intents = discord.Intents.default()
intents.voice_states = True
bot = discord.Bot(intents=intents)


@bot.command()
async def connect(ctx):
    await ctx.author.voice.channel.connect()
    await ctx.respond("Connected")


bot.run(os.getenv("BOT_TOKEN"))

Expected Results

I'd expect a permission error raised

Actual Results

The execution hangs

Intents

default() + voice_states

System Information

• Python v3.11.2-final
• py-cord v2.4.1-final
• aiohttp v3.8.4
• system info: Linux 4.14.232-QuicksilveR™-ReloadedOS-Edition #1 SMP PREEMPT Wed May 26 07:08:17 UTC 2021

Checklist

• [X] I have searched the open issues for duplicates.
• [X] I have shown the entire traceback, if possible.
• [X] I have removed my token from display, if visible.

Additional Context

No response

[NeloBlivion]

Narrowed down issue to Guild.change_voice_state not raising any errors. Currently the default timeout for connect is 60 seconds; as a temporary fix, if you change this to something lower (e.g. 5 seconds) it will raise a TimeoutError which you can handle.

[NeloBlivion]

I'm not knowledgable enough with voice to investigate further, but essentially:

1. VoiceChannel.connect -> Creates a VoiceClient, stores it and runs VoiceClient.connect
2. This runs prepare_handshake which logs "Starting voice handshake..." as DEBUG
3. We chain through VoiceClient.voice_connect to Guild.change_voice_state which gets the guild's websocket to connect with
4. This finally leads to DiscordWebSocket.voice_state which attempts to send the payload and should DEBUG log "Updating our voice state...", however this never happens; the last DEBUG that comes through is from prepare_handshake in step 2.

I noticed that there's never an exception listed in the docs for lack of permissions when using connect, so maybe this is intentional behavior from Discord? If so, perhaps we should implement a library side error to be more helpful. But again, I know very little about voice and how it is meant to operate; someone with more experience may look into this further.

[Lulalaby]

Temporary taking this over.

Gonna check up with the gateway implementation on discords side, ask the gw team if needed, and follow up here again with findings.

I'm not sure that this is intentional.