-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix possible NPE when trying to get encoder protocol #3760
Conversation
I can confirm that this issue is indeed happening currently, even when using the official API. The PR looks good. |
i would just check if ch.isClosed() { return } in serverconnection and userconnection #sendPacketQueued |
I don't think this will fix this problem. |
everything can be an racecondition for this specific case, as it can be invoked indirect via api (that can be executed async). I think just wrap it with an eventloop execute is the most secure way edit: and check if the connection is already closed inside the eventloop |
Any updates on this? @BoomEaro |
looks good to me, have you tested it? |
Everything seems to work fine, but I'll try to test it some more |
This pull request fixes a rare race condition where the proxy can try to send a packet to a queue when the connection to the player has already been closed and netty has managed to clear all handlers, including MinecraftEncoder and MinecraftDecoder, causing a NullPointerException.
This can usually happen when a player who is already trying to connect to another server unexpectedly disconnects from the proxy, and when the server the player was connecting to kicks the player, which in rare cases causes a connection error message to be sent to the player whose connection is already closed.
The solution to the problem seems simple:
Just return null for those methods that return Protocol if there are no handlers.Schedule eventloop to add packets to the queue when necessary.