Open valaphee opened 1 month ago
I'm not fond of the notion of solving these sort of issues on our side because it starts to introduce a whole bunch of extra state that we need to manage which gets fun because of how many broken clients exist, especially around this system...
Though, I guess that that would be a fair hackaround for this solution to try to minimise what is happening. I really do want to rewrite a whole bunch of the server transfer stuff, but, it's a fair while aways before I can really commit to taking on such a project
I want to say that there is already a mojira ticket for this issue?
Fair, for completeness https://bugs.mojang.com/browse/MC-272506, but it's not that common that they fix 3rd party issues even though they introduced a lot of stuff for 3rd partys recently.
And this wouldn't help for versions prior the version where it might get fixed.
This is a race condition regarding a system they implemented, it's likely not a priority for them, but, it is on their side; We'd need to see if we can mitigate it reasonably for affected versions, but reducing the amount of hackarounds in effect for any version is always nice
Due to chat signing, after a server switch / join packet the client spins up a future which fetches the player session and sends it to the server.
Sometimes server do multiple switches closely together (but still after the first one in Velocities view is finished), and if the player has a slower/unstable connection, the player session packet is sent during the config phase which causes an exception and results in a disconnect.
Contents of the log![image](https://github.com/PaperMC/Velocity/assets/32491319/47743187-5812-4184-930d-199b7152ac0d)
Culprit in the client
To circumvent this it might be necessary to wait for the packet to arrive with a timeout (3 seconds should be enough)