Lavalink seems to drop the configureResuming OP if it was sent too early even after websocket open.
I did verify that the configureResuming method was being called and that the data was sent over the websocket.
In testing, I found that waiting 5000ms (I did not test lower timeout durations), then attempting to configureResuming works as intended.
Before implementing a timeout before calling the configureResuming, I noticed some strange behavior;
If the configureResuming method was called at a later time, the OP would go through and resuming would be configured properly. If you disconnect and reconnect within the resume timeout duration, configureResuming would work as intended. If the client fails to reconnect within the configured resume timeout, but attempts to configureResuming outside of that window, the OP would be dropped again.
Lavalink seems to drop the configureResuming OP if it was sent too early even after websocket open. I did verify that the configureResuming method was being called and that the data was sent over the websocket. In testing, I found that waiting 5000ms (I did not test lower timeout durations), then attempting to configureResuming works as intended.
Before implementing a timeout before calling the configureResuming, I noticed some strange behavior; If the configureResuming method was called at a later time, the OP would go through and resuming would be configured properly. If you disconnect and reconnect within the resume timeout duration, configureResuming would work as intended. If the client fails to reconnect within the configured resume timeout, but attempts to configureResuming outside of that window, the OP would be dropped again.