Repository navigation
dialog action commands longer than the chat limit disconnects the player #14212
Description
Expected behavior
You run the command and it sets the player head texture to the texture you want
Observed/Actual behavior
You are kicked from the server with error:
lost connection: Internal Exception: io.netty.handler.codec.DecoderException: Failed to decode packet 'serverbound/minecraft:chat_command'
Steps/models to reproduce
dialog show @p {"type":"minecraft:multi_action","title":
{"text":"Set Texture"},"inputs":[
{"type":"minecraft:text","key":"value","max_length":200,"label":{"text":"Text"}}
],"actions":[
{"label":{"text":"Apply Texture"},"action":{"type":"minecraft:dynamic/run_command",
"template":"item modify entity @s weapon.mainhand {function:\"minecraft:set_components\",components:{\"minecraft:profile\":{properties:[{\"name\":\"textures\",\"value\":\"$(value)\"}]}}}"
}}
],"exit_action":{"label":{"text":"Cancel"}}}
- copy the code above into a command block
- put a blank player head in your main hand
- trigger the command block
- enter this in the box:
eyJ0ZXh0dXJlcyI6eyJTS0lOIjp7InVybCI6Imh0dHA6Ly90ZXh0dXJlcy5taW5lY3JhZnQubmV0L3RleHR1cmUvNzIyODYzMjRiNmIwNmMyZDRjMWQ4ZjgzYTliMTQwZDdjYWJkODI4MWRiOTcyYjI0M2QyZTYyZDFhMjNkMDA1NCJ9fX0= - press the Apply Texture button
- observe that you are kicked from the server.
Next thing to try:
- try steps 1-5 on a vanilla minecraft server with no paper installed
- observe that it works and sets your player head with no error
Plugin and Datapack List
None
Paper version
paper-26.2-117
Other
The following code can be ran to show that below the limit, the dialogs do indeed run correctly in Paper normally.
dialog show @p {"type":"minecraft:multi_action","title":
{"text":"Set Custom Name"},"inputs":[
{"type":"minecraft:text","key":"value","max_length":500,"label":{"text":"Text"}}
],"actions":[
{"label":{"text":"Apply Name"},"action":{"type":"minecraft:dynamic/run_command",
"template":"item modify entity @s weapon.mainhand {function:\"minecraft:set_components\",components:{\"minecraft:custom_name\":{\"text\":\"$(value)\"}}}"
}}
],"exit_action":{"label":{"text":"Cancel"}}}
I suspect that the dialog may be sending packets that are counted as invalid when they are valid on a vanilla minecraft server.
Activity
masmc05 commentedon Aug 24, 2026
It's kind of expected, if I remember correctly there's no distinction to the server between a chat executed command and command executed by clicking, if there were then there would be mods that would just make all comand executions as click event executions, resulting in potential crashes.
The only solution for your case is using custom clicks and handling them with a plugin
And are you sure you ran this on a server and not singleplayer?Nvm the issue is that in vanilla it's validated only client side, on paper it's also validated server side for crash preventions, configurable with-Dpaper.maxChatCommandInputSizesuperstorm192 commentedon Aug 24, 2026
Yeah, I tested it on a brand new empty server just in case and on that server it worked just fine, added paper, kicked. The
-Dpaper.maxChatCommandInputSizemight help, thanks. I hope there's a way to get dialogs to work like that, but if i can't for other servers, i could just for mine.ItzMatick commentedon Sep 30, 2026
Vanilla client sends UI actions as a standard ServerboundChatCommandPacket. What if we moved the max size validation from the Netty decoder up to the PacketListener? That way, we could check if the player currently has an active dialog before kicking them.
electronicboy commentedon Sep 30, 2026
The server doesn't know if the client has a dialog open or not
ItzMatick commentedon Sep 30, 2026
What if we implement state tracking for this? When sending a dialog packet to a player, the server could temporarily save the expected packet prefix for that specific player.
Then, when the next ServerboundChatCommandPacket arrives, we can allow a higher size limit only if the command matches that saved template. To prevent abuse, this exception would still enforce a reasonable hard cap, and the expected state would be single-use, time-limited, and include a cooldown.
Also, regarding dialogs shown via the Paper API, what if we added a parameter to define the maximum expected size of the response?
I'm new to Paper, so these are just some ideas. Feel free to let me know if this approach wouldn't work or if there's a better way!
electronicboy commentedon Sep 30, 2026
The client doesn't tell us when it opens a dialog or when it closes one