Gamershy

H-how does this even happen, mojang....?

Buddy, you're a user, not an admin. Stop acting like an admin.

Then it shouldn't be listed under realms, it should be listed under the normal game's bug reports lmao.

It's not realms exclusive. It affects Singleplayer as well.

Oh wow, I actually forgot this bug even existed after all this time. Guess it's finally happened enough to be considered an actual issue.

Isn't it like, illegal to force users to give information like this with no way to opt out without them explicitly agreeing to it upon downloading the game? Kinda scummy, Mojang... you're gonna end up killing yourselves at this rate..

So, my question is, since this is apparently now WAI, how are we meant to separate chests from boats/minecarts now? Putting it in a crafting grid?

From what I've seen, it seems like the "Show in store" button may be the culprit. As you'd expect, custom skin packs fail to be in the store for obvious reasons, but the game seems to wait for that "show in store" button to load. Since it never will, the UI never updates to display the equip button. An easy fix should be to disable that check for when a custom pack is loaded.

Wow. It's about time someone actually realized why this is a problem... only had to make a second report that was instantly shot down...
Seriously though, please get this fixed, it's a fairly serious issue.

This is still not fixed, and is affecting the latest version of the game. How has it not been fixed, this literally makes Haste 1 beacons useless.

That, right there, is the issue. They should NOT be the same. But, whatever. I'm done reporting bugs for a game where the devs don't even try to fix "smaller" issues.

How to reproduce:
Apply the behavior pack provided in the report in a singleplayer world
All commands use "." instead of "/"
Attempt to use ".spawn", you should be teleported to "0, 116, 0" (location of my server's spawn)
Have any number of other players join
They should all be able to properly use ".spawn" as well.
Apply the behavior pack in BDS
Have the same players join as before
Some players will be able to use ".spawn" to teleport, others cannot as Gametest is failing to detect their message

Expected Result:
All players should be detected in the Gametest Framework's chat detection

Observed Result:
Chat detection is highly inconsistent and seemingly random as to which players it listens for.

Items in Bedrock lack the "rarity" colorization Java has, with the exception of enchanted items turning light blue.

Also confirmed, set up the TNT multikill trick and through the TNT kill was patched out, turns out it's just all broken.
I'm assuming the thorns change tweaked something in the damage calculation and removed the Skeleton Damage type or something.

I'm unsure if this issue still occurs given its extremely specific circumstances, but I've been watching for it. I recently built a new auto chicken farm in a new world, so my personal testing is ready to begin again

Still an issue in 1.17.30. This is such a simple button mapping patch, how has it not been fixed yet?

Okay so, I don't know how much water this will hold, but I have a strong idea as to WHY this bug happens, and for HOW the despawn can be understood.

It's already been established that the primary problem with entities being randomly deleted from existence can be traced to chunk borders.
To my knowledge, when the game saves chunks, it doesn't do so in a massive lump. It saves each chunk one at time, validates the data, then moves on. To us, this is unnoticeable, and it happens so quickly that it seems negligible, but in this case, it's not. Something I've noticed when just sight-seeing in my world is that far away entities do NOT move smoothly from one point to another, rather, they "teleport" between what appear to be pathfinding checkpoints to reach their destination, often skipping 2-3 blocks at a time. This is likely a method of resource management as the game doesn't need to calculate precise movement for the entity, but rather just roughly moves them to where they want to go.
So, let's build a scenario that would likely recreate this bug:

Most players that visit villages only spend a small amount of time in one, just to do some trading or raiding. So we can safely assume the village is going to be either at the edge of sim distance, or be unloaded while villagers are still moving. If my assumption that chunks are saved one at a time, validated, then moved on is true, then we can see where an issue can lie. Let's say a villager is standing in chunk B. Chunk A is next to it, currently being saved. Now, the villager- while Chunk A is still being saved, decides it wants to move to some block that's within Chunk A. The villager is ignored in Chunk A, as the save already occurred. Now, Chunk B is being saved, and as "luck" would have it, the villager is already in Chunk A. This means there's no villager to be saved to Chunk B. Now, suddenly, a villager that VERY obviously already exists is not saved in either of the chunks it occupied. So the next time the villager is unloaded, it no longer exists when you come back, as neither of the chunks saved the villager. This can also happen when the villager is close to you, but obviously would require more precision to occur. Saves also occur when chunks are unloaded, so if a villager was crossing a chunk boundary at around the same time that the chunk is unloaded, the same issue can occur under the right circumstances, especially if the villager leaves sim distance (chunks are not unloaded all at once, but similarly to how they're saved- one at time)

As for a solution? Don't save entities with chunk data, or at least, prioritize all loaded (or known unloaded) entities to be saved FIRST, before the blocks of the chunk data.
What this would mean is when the game initiates a save all entities are saved internally, possibly to ram, to create a sort of "snapshot" of the entities' positions. Then, when chunk data begins to be saved, any checks to save entities call for the snapshotted positions as opposed to the true positions. This means that even if a villager crosses a chunk border at the same time that the game swaps to save the chunks as described in the scenario, it'd have no effect on where the villager will be saved. The only potential issue this could introduce is mobs being in slightly different positions than when you left, which would likely be unperceivable. In theory, this would entirely solve mobs being despawned at chunk borders.

This whole thing could also explain the random disappearances when you consider the teleporting movement when entities are far from the player.

Will do so in a moment

Golden, the issue also occurs when the chunk is unloaded at the same time that the movingblock entity is meant to be removed. 

This is still an issue as of 1.17.10, and betas.