adding an attahcment on a block entity in the block entity load simply makes the game dedlock as it tries to load into a world, no errors whatsoever.
This means If a BE is near the player as it enters the world, world loading will stop at a random percentage and just stay there forever

For reference, I've also encountered this issue before and discussed what causes it in the Fabric discord here.

Same issue happens with BLOCK_ENTITY_UNLOAD.

Can't fabric mark changed be changed to do nothing if chunk isn't completed yet?

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 may not be saved properly.

was this solved?

I even get this now, note this happened even by running a TickTask in that event .

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 completes so the deadlock is avoided.

However I ran into the exact same attachment sync problem like you mentioned above. I believe it is partly caused by a vanilla bug that makes it possible for clients that haven't received a chunk's data to get attachment sync packets for block entities in that chunk. Hence the disconnect for an unknown target.

Though from my testing it seems block entity attachment syncing in general can just randomly be a little flaky, and I haven't been able to figure out why.

My temp solution was to schedule a task for the next tick (I tried with server.tell but that will just make it run immediately if server has time despite it being set to s further tick). To note that the reason I want this is that I needed my attachment to be initialized on its own. Perhaps an API change that allowed automatic intializstion of attachment to objects would be the proper way to have this