Bundle packets are handled incorrectly

[Leymooo]

• This issue is not solved in a development build

Describe the bug
First of all you need to check outPackets, because packets is never updated.

ProtocolLib/src/main/java/com/comphenix/protocol/injector/collection/OutboundPacketListenerSet.java

Line 61 in f606cc9

if (packets.iterator().hasNext()) {

Secondly BundlePacket instance can be shared between multiple players, so i think you need to swap old BundlePacket instance with new one if some plugin changes handle or cancels any of inner packets. If one plugin cancels some inner packets for one players, it may not want to cancel that same packet for other player in case of shared BundlePacket instance.
paper 1.21.11 code:

Leaf fork for example uses shared instances in more places.

And last one, for performance purposes i think its better to copy inner packets only if some plugin actually do something what requires copying (cancelling or using event#setPacket(newContainer) or null inner packet) in other cases it just waste of resourses. I think you can check if Iterable is RandomAccess and create 2 execution pathes -one with lazy init + indexing tracking, second is always copying while iterating.

To Reproduce

Expected behavior

Screenshots

Version Info

Additional context

[Leymooo]

Also looks like you didnt use right constructor when creating PacketEvent for subPacket. I does not init bundle field.

ProtocolLib/src/main/java/com/comphenix/protocol/injector/collection/OutboundPacketListenerSet.java

Line 42 in f606cc9

PacketEvent subPacketEvent = PacketEvent.fromServer(this, subPacket, event.getNetworkMarker(),

ProtocolLib/src/main/java/com/comphenix/protocol/events/PacketEvent.java

Line 76 in f606cc9

private PacketEvent bundle;

[dmulloy2]

Confirmed both correctness issues:

1. OutboundPacketListenerSet checks the original packets iterable instead of filtered outPackets, so a bundle whose inner packets were all cancelled is never itself cancelled.
2. Bundled sub-packet events use the PacketEvent.fromServer overload that supplies a null bundle, so PacketEvent#getBundle() cannot return the parent.

Thank you for the precise analysis. Keeping this open as an accepted bug; the copy-on-write/performance suggestion can be considered separately from these correctness fixes.