Out-Of-Date & Deprecated Dependencies

[JulianDroste]

As mentioned in J4YB3/discord-movie-night-bot#60 I checked your dependencies with cargo audit and found them to be slightly out of date:

• hyper - >=0.14.10

This can be mitigated by placing the following in cargo.toml:

# ...
[dependencies]
# ...
hyper = { version = ">=0.14.10", default-features = false }
# ...

I would also recommend you to divert from the usage of the net2 crate as it has been deprecated in favor of socket2. If you'd like I can open a pull request for the Cargo.toml update.

[SpaceManiac]

Upgrading hyper is not so simple because the websocket crate also depends on hyper ^0.10

[ekshore]

@SpaceManiac I'm attempting to migrate this project off of websocket and over to tungstenite-rs. I have got receiving and parsing events working on Tungstenite, however I'm running into a couple of issues when it comes to voice connectivity. The bot just won't connect to a voice channel. I've been using the DJ bot example as my test scenario, and when I ran into problems I switched the dependency back to main on this repo and I'm having the exact same behavior. The test bot has admin privileges and ALL privilege intents enabled.

Do we know if voice works in the current state of the project? would someone be able to confirm? I'm wondering if discord introduced a breaking change in their API? Or if I'm missing something in terms of bot setup.

[SpaceManiac]

@ekshore I checked and indeed voice wasn't working. I was able to fix it by updating the code to match Discord's voice gateway v4 documentation. Maybe they broke support for some corner case in v1 that the library was hitting. Not sure when that happened as it was working last time I used it.

[ekshore]

@SpaceManiac Thanks for that update, I can confirm that it does now connect to a voice channel. As I've been trying to work on migrating over to tungstenite I ran into some issues with sockets blocking. When I revert back to the main + moving to 2021 edition, I think there is still some blocking going on. Specifically I think the socket send is being blocked while the socket is waiting for a read ultimately causing the socket to disconnect killing the bot. I'm switching gears and going to migrate the websocket code over to tokio-tungstenite instead of just tungstenite.

Let me know if you have any concerns with this approach.

[SpaceManiac]

I would prefer this crate's API stay synchronous/thread-based rather than async. Serenity and others are already filling the async niche. If tokio is just an implementation detail, maybe it'd be okay.

[ekshore]

From the research that I've done we can add the tokio runtime to make use of async sockets under the hood but still expose a synchronous API. I'll work on it and get a PR out there for you to take a look at. If you would like me to have the PR go into a different branch other then main let me know.