## Summary On Fabric, Cobblemon's entity spawn packet handling causes disconnects with Fabric API's attachment sync system due to improperly scheduled entity spawning that delays entity registration on the client. ## Steps to reproduce 1. Install Cobblemon on Fabric with any mod that uses Fabric API's synced attachments which add them to any Cobblemon entities (e.g., Supplementaries, Prometheus, Sleep Tight) 2. Spawn/start tracking an entity with attachments 3. The client will disconnect with `AttachmentSyncException: Received attachment change for unknown target!` ## What is the current bug behavior? Cobblemon wraps entity spawn packet handling in `client.execute()` which schedules the entity spawning as a task rather than executing it immediately. This causes the entity to not exist on the client when Fabric API sends attachment sync packets, resulting in disconnects. From looking at prior commits I would believe this issue previously caused the passenger sync issues (fixed in c0d2803f), where vanilla passenger sync packets arrived before Cobblemon's delayed entity spawn completed. ## What is the expected correct behavior? Entity spawn packets should register entities on the client immediately during packet handling so that subsequent attachment sync packets, passenger sync packets, or other potential sychronization can find their targets. ## Cobblemon Version and Mod Loader Fabric with MC 1.21.1, affects current versions ## Mods used besides Cobblemon Any mod using Fabric API's synced attachment system (Supplementaries, Prometheus, Sleep Tight, etc.) ## Relevant logs, screenshots and/or videos See discussion and debugging in https://github.com/FabricMC/fabric-api/issues/4943 Multiple users report disconnects with error: ``` net.fabricmc.fabric.impl.attachment.sync.AttachmentSyncException: Received attachment change for unknown target! ``` ## Additional Information The issue is in the spawn packet handling code [SpawnExtraDataEntityPacket.kt#L34](https://gitlab.com/cable-mc/cobblemon/-/blob/c88087de29b0173c84c4fecf366bea8563b5b189/common/src/main/kotlin/com/cobblemon/mod/common/net/messages/client/spawn/SpawnExtraDataEntityPacket.kt#L34). The `client.execute()` call schedules entity spawning as a task. On NeoForge, packets are configured to execute on the network thread (see [CobblemonNeoForgeNetworkManager.kt#L34](https://gitlab.com/cable-mc/cobblemon/-/blob/c88087de29b0173c84c4fecf366bea8563b5b189/neoforge/src/main/kotlin/com/cobblemon/mod/neoforge/net/CobblemonNeoForgeNetworkManager.kt#L34)), so the `client.execute()` call properly moves execution to the main thread. However, on Fabric, packets already execute on the main thread, so `client.execute()` with client being `ReentrantBlockableEventLoop` schedules it as a task instead of executing immediately, causing the delay/out of order sequencing. Additionally, there are other packets which make use of this scheduling that need to be updated as well, such as [ClientboundUpdateOrientationHandler.kt#L20](https://gitlab.com/cable-mc/cobblemon/-/blob/c88087de29b0173c84c4fecf366bea8563b5b189/common/src/main/kotlin/com/cobblemon/mod/common/client/net/orientation/ClientboundUpdateOrientationHandler.kt#L20). The fix is to move the `client.execute()` scheduling outside of common code so only NeoForge uses it (where it's needed to move from network thread to main thread), while Fabric executes immediately. Alternatively, change registrar to use `executesOn(HandlerThread.MAIN)`.