Dedicated method for requesting voice states

[gudvinr]

Description

While skimming through docs I didn't find a way to get current list of voice states for guild/channel on demand.
Only viable solution that probably exists is to track voice states of users in every guild your bot joined.
That also means you can't just use VOICE_STATE_UPDATE event but handling GUILD_CREATE events also required.

Thus, I suggest adding ability to get voice states without tracking them from beginning.

However, there are definitely some complications:

• You can't return these states using REST API since response might contain outdated information. Users might jump to another channels, leave, etc during request.
  It is also likely that user presences and voice states handled via separate service which may not communicate with REST at all.
• Even if you can, you can't update received data using VOICE_STATE_UPDATE because you can't possibly know which updates response already contains

So, that means there are basically two ways of doing so:

1. Through new gateway command
2. Using REST API but only to notify gateway about our intention to receive voice states

Then, gateway might return either new event with initial states (under GUILD_VOICE_STATES intent) or bunch of VOICE_STATE_UPDATE events.

I am leaning to the former since in latter case there's no way to know whether VOICE_STATE_UPDATE was sent as a regular update or as the result of bot request. Unless there's some field to set nonce to indicate that.

Why This is Needed

While it is makes no difference for bots that need to interact with voice channels, it kinda hurts memory-wise for bots that need to take action on specific channel by request.
Especially with slash commands, when you might want to pass channels to bots.

I found this issue when I tried to implement new slash command where bot would interact with users in specific channel passed through command option.

So basically it is needed for cases when tracking of voice states is not wanted until someone want to start tracking. In that case it is more useful to retrieve fresh state and continue to track and skip these events otherwise.
But right now you can't skip these events at all and what's more important you must store at least uint64 per user in every voice channel in every guild.

Alternatives Considered

As mentioned earlier, only option that I am aware of is to retrieve voice states from GUILD_CREATE and listen to VOICE_STATE_UPDATE events.

[wasdennnoch]

I've just run into this issue too. I want to create an interation-only slash command which checks a user's voice state, in order to see if a user is in a specific voice channel. However, as it turns out, while there is an API for fetching a Guild Member now, there is no such API for fetching voice states. As described above, the only way to keep track of voice states right now is to spin up a gateway connection and cache data about every voice state.

As Discord is moving to support stateless bots with the introduction slash commands, there should also be REST replacements for as much gateway functionality as possible. For instance, there are now endpoints to list and search guild members, which was previously a gateway-only feature. There should be a similar endpoint for listing voice states in a guild, and fetching voice stats of individual users.

I don't agree with OP's argument:

You can't return these states using REST API since response might contain outdated information. Users might jump to another channels, leave, etc during request.

Gateway events aren't instantaneous either. The bot might very well interact with stale data just before the VOICE_STATE_UPDATE event arrives, especially in cases of high ping - if it even arrives, which technically isn't guaranteed (though admittedly unlikely not to happen, except during an outage). This is the case for any gateway event.

Additionally, since stateless, interaction-only bots running on services like Cloudflare Workers can't even interact with the gateway, a REST endpoint is definitely required.

[gudvinr]

Gateway events aren't instantaneous either

@wasdennnoch they don't need to be instantaneous. But they surely should be streamed.
The thing with REST is you don't really know when user had state that you got as result. You can't assume that some particular user didn't change his state from the time you got slash command when you receive response with user states.
Gateway will provide you a way to get states that you actually can use safely unless you want to get outdated states. Especially when you must handle a huge amount of guilds.
Of course there is some delay, however, it is one way stream over established connection rather than request-response where you need to connect and do a handshake every time.

[ghost]

The thing with REST is you don't really know when user had state that you got as result.

This makes no sense. The state you get back from the REST request is the state at the time you made the request.
If you have a cache and you fetch state from cache, it will be the state at the time that you fetched from cache.

You can't assume that some particular user didn't change his state from the time you got slash command when you receive response with user states.

This can also be read as: You can't assume the user didn't change their state from when you get the message create event to when you fetch from cache. The only difference is that requesting state from the API takes a few hundred milliseconds more than fetching it from cache. If there was something you did not cache, you would have to do the same thing - for example, many larger bots do not cache guild members, and as far as I know, there aren't usually issues where the user changes their member state between a command invocation and the command response.

[gudvinr]

The state you get back from the REST request is the state at the time you made the request.

This assumption is only true if REST API handled by same service that stores and updates voice states. Which I really doubt is the case.
But that doesn't actually matter. In guilds where users interact with voice channels heavily you will be getting responses that might be outdated by the time you receive them. Hundreds of milliseconds is a huge amount of time for such kind of events. User presence/voice state updates a lot more frequent than e.g. nickname changes.

[wasdennnoch]

That doesn't change the fact that it's completely overkill to have an active gateway connection just for receiving voice state updates, and it contradicts Discord's current push for stateless bots. Dpending on the runtime environment you can't even spin up such long-lived connections (Cloudflare Workers, Amazon Lambda, or whereever else you can host an interactions-only Discord bot), which means that a REST endpoint would be by far the best solution in this case. I don't care if the voice state might be outdated by half a second - having a 0.5 seconds stale voice state is infinitely better than having no voice state at all.

[elliotgoodrich]

I also would like a REST endpoint to get a list of all voice states at a particular point. It wouldn't matter to me if it isn't 100% accurate as it is the only way that my serverless bot can get this information.

[gudvinr]

I don't care

But I care about that. And since it is important for me, I specifically mentioned it in the issue that I created. My use case that doesn't have stateless bots in mind thus what I don't care about is runtime environments that do not have an ability to utilize long-lived connections.

[ghost]

But I care about that.

[...] in the issue that I created.

Nobody said you can't ask for a gateway command to request a voice state. You, however, are saying others cannot ask for a REST endpoint to request a voice state. While it is true that you created this issue, it is unreasonable to expect people not to comment with their own opinions and use cases and what they would ask for.

[gudvinr]

You, however, are saying others cannot ask for a REST endpoint to request a voice state.

I never said that. What I am really saying is that REST endpoint wouldn't be sufficient for the cases where you need to track states in realtime-ish manner. Or, in fact, in that particular case REST endpoint may not be even possible/hard to implement until proven otherwise.
If someone doesn't care about correctness of voice states, it doesn't make gateway events overkill. That's all.