When using the new synced attachment API I often get this.

22:50:04] [Render thread/ERROR]: Error accepting attachment changes
net.fabricmc.fabric.impl.attachment.sync.AttachmentSyncException: Received attachment change for unknown target!

Does it need to hard fail like that? If the target clearly exists on the server given the attachment is accessed there

I think it should fail hard, as it likely means there is a more concerning issue elsewhere. Do you know what target its trying to sync to? Or have a way to reproduce this with a minimal amount of code.

I'm only executing some logic on entity tick, getJumpBoostPower entity method and when an entity is hit by another entity.
I dont see how this could be part of a bigger issue also because a very similar implementation works on neo, which I'm only bringing up since the 2 impls are suspiciously similar which makes me think they were made by the same person.

Anyways one crucual difference is that you dont have control for when stuff is synced here, merely setting the attachment sends the synced packet so i dont even know what one could do to prevent this.

Moreover wouldnt this issue happen all the time when a server entity data is accessed? since client doesnt have most of the server entities as they could be in far away chunks or newly added one and hence the client would fail to find it

you dont have control for when stuff is synced here,

You do, use a custom AttachmentSyncPredicate

since client doesnt have most of the server entities as they could be in far away chunks

We only sync the attachment changes to targets that are being tracked by the client. We shouldnt be sending changes to the client that will be ingnored, the data shouldnt be sent in the first place.

I really need some more info or a way to reproduce the issue you are having.

I am working on that. I haven't been able to replicate it myself. People reporting it crashing with just my mods. Still idk what I could be doing wrong, all I'm doing is get and set attachment operations

I can't replicate on my own. People here claimed they can trigger this after having just update my mods which replaced a mixin based impl with a simple data attachment https://github.com/user-attachments/files/23111749/latest.log

I believe that whenever underlying issue might be here should be logged better since it's extremely hard to track down given it happens in connection. Also doesn't happen on neo which had a very similar API at least

Attachment identifier: supplementaries:slimed_data
World: minecraft:overworld
Target type: Entity
Entity network ID: 169669

Unfortually this is basically all the info we have, it would be helpful to know what entity has 169669 as its id on the server. Do you set your attachement on all entities or just specific ones?

You can see in the above code that we should only be sending these packets to clients that are tracking this entity. As far as I know there shouldnt be a case where the server thinks the entity is being tracked, but the client doesn't. Maybe there is a race when the entity is being untracked?

I set it to all living entities, on first tick they will basically be all initialized

Could it be a mod adding a server only entity?

Could it be a mod adding a server only entity?

Quite possibly yes, the vast amount of mods this user has doesnt make it easy to figure out whats going on. There are other logs from somewhere (A quick github search suggests the accessories mod) that suggest similar issue:

Unable to Sync Container Data for a given Entity as it is null on the Client! [EntityId: 169671]

I notice they are in single player so it wouldnt be impossible to get more info from the intergrated server about this to improve the logging. 🤔

I'll get to the bottom of this. Printing all the entities IDs on server and hoping they match the one on the client

I'm working on getting that. This couldnt be caused by entities that are not adde to the level? that would be something totaly valid that mods might do

here's another log. so many entities ID are mentioned which makes me thing all entities are affected.

latest - 2025-10-25T030444.363.log
Really the only thing i'm doing is accessing those data, i dont have anything weird going on so i really dont see how it could be my issue. Idk how another mod could affect this either

@modmuss50 I found a setup to replicate: Synced attachment, get using a mixin in LivingEntity "tick" method + cobblemod mod (for some reason, I dont think its exclusive to this one as Ive heard it happen without) + create a new world, fly around and relog.

Any update on this?

I have spent a solid hour looking at this, I can only reproduce this when the cobblemon mod is installed. I was able to confirm with a debugger that the bundle packet containing the inital entity data is always sent before the attachment updates for that entity.

However when cobblemon is installed the packets are handled on the client out of order, meaing the entity has not yet been added to the client world before the attachment change packet is handled. I am struggling to figure out how this is possible.

I can reproduce this too using Fabric API, Sleep tight (1.21-1.3.4 or latest for 1.21.1), moonlight-1.21-2.25.3 or latest for 1.21.1 and running around with 99 speed on 32 render distance loading villages. The beds in the villages loading in causes this error to popup.

Seems like downgrading works for now, Fabric API 0.115.4 for 1.21.1 is stable (You'll have to remove fabric-api dependency from sleep tight), anything beyond is not. This bug could be related to what was in the changelog for [1.21.1] Fabric API 0.115.5+1.21.1 , as it doesn't seem to affect versions before that.

Hope this helps.

Bump version (modmuss50)
AttSync: Disconnect when attachment target is null (#4538) (#4586) (Octol1ttle, modmuss50)

Downgrading isn't a solution, as before this change it would leave your game in a bad state. There is something odd (or at least something I don't understand) going on with the order in which packets are handled on the client.

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 custom packet is submitted to the client's task executor (mojmap), taking the handling of that packet out of the usual vanilla packet handling flow.

Since packets that need to be processed on the main thread are executed first before tasks submitted to the client executor, the att sync packet ends up being processed first before Cobblemon's custom packet.

I haven't fully verified this yet but it's quite likely this is the case.

Very intresting find! Submitting to the client's task executor is correct, and something all fabric packets do by default (including the attachment sync ones). I believe calling this when already on the client thread will invoke the runnable right away, so as long as its sent before the attachments are sent it should still work. 🤔

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 is strange that Cobblemon submits it to the client's task executor when it's not really needed.

So a hacky bandaid workaround could be to delay the attachment sync one tick after it's received if the target isn't valid. Yes mega hack and not correct but would prevent crashes and if it's just an issue due to packet order this should be almost correct behaviour no?
Sort of similar to what I had to do for this which btw is also an issue #4718

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 by other things unrelated to client packet processing order.

Your proposed solution would probably fix all these syncing issues but I'd guess it's almost certainly too hacky for FAPI.

Anything I can do to test further? I've gotten another report due to cobblemon mod. Could it be that It can also be considered that mod issue?

The syncing issues with BLOCK_ENTITY_LOAD are reliably reproducible with just FAPI and nothing else. Basically, it's caused by two issues:

1. MC-299444, which has been marked as low priority and will probably never be fixed. This causes an att sync disconnect immediately upon joining the world if BEs are nearby.
2. When a BE loads into an already loaded chunk (e.g. player places a BE), the att sync packet is sent to other nearby players before the BE's data is sent. The player that placed the BE won't disconnect (cause their client already knows the BE exists) but everyone else nearby will.

So the BE syncing issues are completely separate from the entity syncing issues. Your solution would probably fix all of them in one go but it's quite the hack.

Got this same issue between two mods it seems: Supplementaries and Incendium

(slimed_data is from supplementaries)

13:08:34] [Render thread/ERROR]:Error accepting attachment changes
net.fabricmc.fabric.impl.attachment.sync.AttachmentSyncException: Received attachment change for unknown target!
Attachment identifier: supplementaries:slimed_data
World: minecraft:the_nether
Target type: Entity
Entity network ID: 6981

Does the new fabric version logs instead of throwing?

It has always both logged and disconnected.