[Bug - 1.21.11] Pearls get deleted when switching dimensions.

[coredex-source]

Expected behavior

Pearls should stay, for example, in a stasis chamber until a player dies if using the default gamerules.
Tested it on both Paper and Folia just to be sure.

Observed/Actual behavior

On PaperMC and vanilla Minecraft, the pearls do not get deleted when switching dimensions but on Folia 1.21.11 they do get deleted once the player leaves the dimension.

Steps/models to reproduce

Make a stasis chamber, put a pearl in the chamber and go through a portal to change dimensions.

Plugin and Datapack List

Tested with no additional plugins installed.

Folia version

1.21.11-6-ver/1.21.11@0795007

Other

No response

[SucIXR]

Actually, the reason is quite specific to how Folia handles player data compared to Vanilla/Paper.

1. The Persistence Issue (Why they vanish on restart): In Vanilla and Paper, active Ender Pearls are stored inside the player's NBT data. However, because accessing ServerPlayer across threads is unsafe in Folia, the logic for saving and loading pearls via player NBT was completely removed. This is why pearls do not reappear when a player logs back in—the data is simply never saved.

2. The Dimension/Region Issue (Why they vanish on teleport): Regarding your observation about pearls getting deleted when switching dimensions: This is because Folia performs extensive owner != null checks. Since Folia is multi-threaded, once the player leaves the pearl's current region (or dimension), the local entity lookup returns owner = null. Consequently, the pearl is immediately discarded/killed by the system.

The Solution: To fix this, we need to solve two problems:

How to safely store pearl data into the Player's NBT without triggering thread checks.

How to ensure the pearl keeps running/ticking even when the player is cross-region.

I have implemented a clever fix for these issues in my core. If you are interested, feel free to take a look.

[Dueris]

#423

This already fixes the issue. The dimension/region issue you described is incorrect, as its not owner != null checks, its if the owner is removed.

[AnotherMaskedDev]

Yeah you may have overdone it in your core.
@SucIXR