Basically async usage of protocollib to to send packets is suspected by me and reflex developer to cause packets with zero length to be emitted sometimes(not even a packet id), causing disconnects when bungeecord sits inbetween.

Do you have anything more specific than that?

BungeeCord is basically reading a varint with value zero for length, then trying to read the packet id and failing, because the buffer is empty.

Unfortunaly, no really specific details.
I'll ask reflex developers if they found something more specific.

It exists already at least in ProtocolLib 4.2

Maybe it is also related to packet cancellation and packet sending in packet listeners.

It just occurrs randomly.

I personally do not operate a server, just some issues made to plugin authors.

Edit: Reflex developer said it was fixed by sending packets related to their fake entities synchronized and he did not inspect the issue further.

I have seen something similar come up when modifying server ping packets sync instead of async. If this is the same kind of thing, the listener just needs the async option set. I could also force that lib-side, but I'd need the specific packet type.

Hello @dmulloy2 - I have a server that currently has players disconnect randomly due to allegedly empty packets being sent to Bungee. I would be more than happy to try and debug what is causing this, but I'm not sure what kind of info you would need and how to track it. Cheers!

@dmulloy2 I'm really wondering what could be wrong in code if empty packets aka a single 0x00000000 being emitted occurr based on the listener being executed async or sync.

This all just sounds even more like a big assumption.

Packets involved for fake playersare: player list, named entity spawn, entity teleport & movement, use_entity, entity metadata, maybe entity_properties and entity_effect.

Forcing any packet listeners async by default is not something one should consider - it leads to broken api contract and possible race conditions / cme's in plugins.