Sending plugin message to server on ServerSwitchEvent listener causes disconnect #3519
Comments
Pretty sure this is already the case. The issue is that this is happening in the login phase still. Likely the phase switch just needs to happen a bit earlier. I don't think the event can be delayed until after the configuration phase because bungee needs to cut through to the client in that phase which means updating the players server (getServer) and the event needs to be fired when that happens to prevent plugins having an inconsistent view. |
|
We have similar issues with ProxiedPlayer.sendMessage. When sending a message in PostLoginEvent, ServerConnectedEvent or ServerSwitchEvent the client gets disconnected with something like [06:17:18] [Render thread/WARN]: Client disconnected with reason: Internal Exception: io.netty.handler.codec.DecoderException: net.minecraft.class_151: Non [a-z0-9_.-] character in namespace of location: {"extra":[{"color":"gold","text":"Willkommen, "},{"color":"white","text":"Brokkonaut"}],"text":""} I think the best way to fix this might be to queue those packets from sendMessage or sendData until the connection enters the correct phase |
|
I think sendMessage should be queued, but sendData should be able to be sent immediately subject to my above comment. |
I'm not sure about this solution, because then on server switch (not join) there would be a window for plugins to send packets during configuration phase still. Solutions 1 and 3 would not fix other packets. I believe the only way is to queue all game packets sent during configuration phase. |
|
What other packets? |
|
Literally any. When I tried joining with my plugin, I got disconnected with any of the following based on enabled features: |
|
Is that part of the API? |
|
|
|
if its not api its on the plugin devs side to get it fixed, but all api call should be fixed to work with plugins not specialy designed for 1.20.2 |
How exactly are plugin devs supposed to fix it? How are they supposed to know when is the client in configuration phase and when not? |
|
looking into the bungeecord and minecraft soruce |
Give me an example code then. |
I'm not deep enough in Bungee internals to understand exactly why that would prevent the event from getting called later but from an API-design perspective the event is required to be fired after the configuration phase is done and the connection to the server is fully ready. Otherwise the contract that the API provides would be broken without any deprecation/change notice. (The contract being "Called when a player has changed servers.", not during the change) And seeing as lots of other methods also cause issues when the client is not in the |
|
It has changed though? .getServer returns the new server and packets are actively proxied between the two? I don't see how it could be otherwise |
|
I'm having basically the same issue |
I'm referring to the fact that the server connection is not completely ready to play the game (the "game" phase) when the ServerSwitchEvent is called. That's what I understand under "the server was changed": The player actually being able to play the game on the new server and the change process being completely done. Seeing as they can still be in the configuration or even login phase this is no longer true but was in the past. |
|
Good morning, |
The configuration phase is different from the login phase, because the server can switch back to the configuration protocol at any time. So there is never a guarantee that a connection is in the play protocol in 1.20.2 even if it was in the play protocol and there was no server switch. So I think all that could be done is a better way for plugins to support this (maybe with something like a ConnectionProtocolChangedEvent, an api to get the current protocol and the delaying of some packets (at least chat packets) until the connection has the correct protocol) |
Of course an API for that would definitely be appreciated but this issue is about the changed behaviour of the ServerSwitchEvent which breaks basically any plugin using it to send any kind of data (seems that I don't think expecting every plugin to implement some kind of after-server-switch caching to wait for the The solution should be to either somehow call the event after the |
|
I've implemented the queuing for API methods, I don't see any feasible way to change where the event is fired. Any other issues/suggestions should be a separate ticket. |
|
I'm coming back to this ticket again because I have this problem and I have the latest version of bungeecord (ver 1738) what should I do? |
|
Reproduce without plugins, bungee does not have a team API |
|
I'm also continuing to have problems... Will try to reproduce in the morning without plugins... |
|
My server is also still having this issue on latest version. Joining is fixed now, but when trying to switch servers I get kicked for Internal Exception: io.netty.handler.codec.DecoderException: java.io.IOException: Packet Does this need a fix plugin side? If so, what would be potential the causes of this behavior? |
|
same issue with 1738 Version: |
This is not the same issue, and its unclear what this issue is since the Kick packet is registered in phase CONFIGURATION with direction TO_CLIENT, so you need to provide more info in a separate ticket. |
|
Trawling through GitHub, Spigot MC, Paper Discords and multiple other public discords, it would appear that there are a huge number of plugins / configurations affected by 1.20.2 clients unable to negotiate their way around a bungee cord network. Join event seems to get them into the worlds, but switching servers kicks them with a multitude of errors but all seem to relate to the client being in a GAME phase, and then having to go back in a CONFIGURATION phase again during switch and the packets not being handled &/or queued correctly. Mojang is clear on their release notes that there has been a major re-write of the networking protocol, Im wondering, is this a larger fix than initially thought to ensure compatibility for newer and older clients on the same proxy. from: https://www.minecraft.net/en-us/article/minecraft-java-edition-1-20-2 I don't have the technical understanding of the protocol to be able to advise a fix, but can confirm a clean Bungee 1.20.2 with no plugins and any backend seems unaffected. But add one of many affected bungee plugins and the problem re-occurs. If this isn't a fix on Bungeecord side and a tweak of packet scheduling, then I guess it will be a choice for us all to move many features and functions either to the backend instance or completely re-write Bungee plugins to work around this. Ideally the preferred solution would be a bungee side fix, so existing api's and methods continue to function irrespective of what client version is used to connect. |
|
You're gonna need to be more specific, the above commit 10 hours ago already fixed the mentioned APIs with issues. |
|
Error: https://pastebin.com/dUBUKpD8 I notice in a previous reply in this issue you mention that Team doesn't exist in Bungeecord, but it is referenced in: https://github.com/SpigotMC/BungeeCord/blob/master/protocol/src/main/java/net/md_5/bungee/protocol/Protocol.java Disconnect message:
|
|
The commit does not fix anything, not even the API. Using the API gives me this (also thrown when using sendPacketQueued directly for other packets): When sendPacketQueued does not throw, the packet may get lost when sent during configuration phase (happens 100% of the time for scoreboard packets). Then, on server switch, I get disconnected with: or this or this |
|
Still getting the same error and kick on the latest BungeeCord (f9b75c4:1739). It looks to me like As far as I can tell 0509303 only addressed the direction to the client, not to the server. The "new" error (still the same as before): |
|
@Phoenix616 see 497c687 |
Ah, you managed to fix that while I was writing up the comment! This solved my issue, cheers! |
|
Unfortunately looks like I'm still having issues with the latest release... |
|
bungeetablistplus is not using the API |
|
I am not using bungeetablistplus and I'm using the latest version of BungeeCord. Using a Bungee command like
This happens for any Paper server as the sub-server 1.8-1.19 from what I have tested (and latest ViaVersion installed) Is there a fix for this? Do I need to open a new issue for this? |
@Override
public boolean onCommand(CommandSender sender, Command command, String label, String[] args)
{
Player player = (Player) sender;
ByteArrayOutputStream b = new ByteArrayOutputStream();
DataOutputStream out = new DataOutputStream( b );
try
{
out.writeUTF( "Connect" );
out.writeUTF( args[0] );
} catch ( IOException ex )
{
// Impossible
}
player.sendPluginMessage( this, "BungeeCord", b.toByteArray() );
return true;
}Works fine for me, and yes separate issues should be a separate ticket. Viaversion is also not supported. |
|
We are experiencing a similar error to gre3x's when a player switches server.
(quoted error from above) However, it only seems to occur when the player is moving whilst switching server. If stationary, they're not kicked. |
|
This issue shouldn't have been closed yet, as the issues still exist and this just creates confusion when its supposedly fixed when it is not. If you need fundraising or something to get this stuff fixed, do let us know. We have players waiting and they are not very patient. |
|
You have provided no new information which suggests that it is not fixed. |
|
I am still getting this issue |
Which issue? Where is your stack trace/logs? |
|
Since this conversation is live now and I am not able to test it myself anytime soon, I'll ask. Was #3519 (comment) fixed? I didn't receive any feedback on it. |
No because it's not part of the API and also its not the subject of this issue. |
|
|
Apologies, that specific method has been fixed |
|
In build 1751 when calling |
|
|
Should I open a new issue? What should I do if there is no API? |
Propose API in form of an issue or even better PR ;) |
|
Looking at the 110 open PRs and 256 issues I don't think it would do anything. |
I'm unsure what that has to do with anything. Issues that can be closed/resolved will be and PRs that are merge-able get merged. The amount of issues and PRs that aren't in such state is no indication for anything (beyond that a lot of people seem to not care enough to follow through with their stuff...) |
Did you look at the 816 closed ones (88%) |
|
Will the kicking get fixed? It doesn't seem like there's any way to even debug what plugin causes it and it needs a fix. |
|
Locking this ticket as the original issue has been resolved and subsequent comments appear to describing different issues with insufficient information which would be better suited to a new ticket complying with all requirements. |
Bungeecord version
git:BungeeCord-Bootstrap:1.20-R0.2-SNAPSHOT:f486a25:1737
Server version
3877-Spigot-17ca32d-f070277 (MC: 1.20.2)
Client version
1.20.2
Bungeecord plugins
BungeeResourcepacks
The bug
When switching servers you can get disconnected with several different errors. Some of those point to invalid packets in the CONFIGURATION phase (see the log for an error where this is pretty clear, there is also a similar but different error by a user of my plugin: https://hastebin.com/share/eqekunelay.css). The code point mentioned in this log is sending a plugin message with
Server#sendDatain a ServerSwitchListener.This breaks how the API worked before and other things that could trigger packets to the server (or even client? seeing as the
SystemChatpacket is also mentioned in the error) in that phase might break too.Possible solutions that I could think off:
Log output (links)
Alternative error: https://hastebin.com/share/eqekunelay.css
Checking
The text was updated successfully, but these errors were encountered: