FabricMC
Oversized data attachments cause server crash when synced
When a data attachment is set to sync with clients and has a encoded size > 32502 bytes, the server crashes when tying to send the attachment.
---- Minecraft Crash Report ----
// Why did you do that?
Time: 2025-05-31 14:26:26
Description: Exception chunk generation/loading
java.lang.IllegalArgumentException: Data for attachment 'worldgendevtools:feature_positions' was too big (32768 bytes, over maximum 32502)
(crash report from downstream bug report: https://github.com/jacobsjo/worldgen-devtools/issues/16 ; I'll update it when I reproduce this myself)
How to handle these oversized data attachments is a different question, but crashing the entire server is clearly not the desired outcome.
It would probably be possible to switch the payload to use a split payload if anyone has time
I'd be willing to make a PR for this, though I'm wondering what would be a suitable new max size for individual attachments and the att sync payload.
I wonder if the proper solution would be for mods to say how big they want their attachment to be?
Possibly, though a fixed limit would still be needed for the att sync packet itself. I was hoping that by setting a high enough limit, manual packet splitting for initial syncs could just be removed, but if mods can set their own limits per attachment then manual splitting might still be needed.
Other parts of FAPI seem to use system properties to specify the size limit, that could work here
I think having a per-attachment-type customizable limit that mods can set is the best solution
I think having a per-attachment-type customizable limit that mods can set is the best solution
It might solve some issues, but not the one I've reported in this issue. This issue is about the very harsh handling of oversized packets, which can happen no matter what the limit is set to.
If it's sending packets to the client I don't see a problem with the server crashing. If it's crashing when receiving stuff from the client then that's very bad. However we should probably put a try catch around it and kick the client on an exception