DennisOchulor

For reference, I've also encountered this issue before and discussed what causes it in the Fabric discord [here](https://discord.com/channels/507304429255393322/566276937035546624/1374058698443325512). Same issue happens with `BLOCK_ENTITY_UNLOAD`.

The API could call `BlockEntity#markDirty` via a server task if the chunk is still loading to avoid the deadlock but it can't just do nothing otherwise the newly attached data...

I have actually tried to solve this issue and came up with this implementation It gets the chunk's future and calls `markDirty()` if the chunk is present when the future...

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.

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...

I assume number 3 would be something like `PayloadTypeRegistry.modifyLargePayloadMaxSize(id,size)`? Though depending on mod load order, mods registering large attachments may cause `modifyLargePayloadMaxSize()` to be called before the att sync packet...

I've implemented @Earthcomputer's suggestions, the changes to the networking API are in a separate commit to help with reviewing. Though maybe a separate PR should be made?

I believed I've potentially found the issue. For certain entities (e.g pokemons, pokeballs) Cobblemon sends a custom entity spawn packet that wraps the vanilla one. Then on the client, the...

Oh yeah I forgot all custom payloads are forced onto the main thread by Fabric, in which case yea it should still be processed in the correct order... Though it...

I have actually figured out a fix for #4718 so that the deadock is reliably avoided, but now that the it doesn't deadlock it runs into attachment syncing issues caused...