When a chunk resumes ticking after not being ticked for a while, the game checks for mobs colliding with blocks and resolves them by displacing the mob if possible. However, the rules used at these times to resolve collisions with (at least certain) nonsolid blocks are different from those used during continuous gameplay. This causes mobs to be unexpectedly displaced at times long after the collision occurred, such as the first time a player comes near after reloading the world or returning from another dimension.
Impact: I first noticed this in a villager breeder that holds two villagers in a 1 x 2 x 2 space where they're standing on a pair of adjacent glass panes and trapdoors are folded down over their heads. (This is a well-known and common design.) During building and subsequent gameplay, the collisions of the trapdoors with the villagers does not displace them, but if you save and reload the world, or leave and return via a Nether portal, or probably if you move out of simulation range for a long enough time, when ticking in the chunks resumes one of the villagers will almost always glitch down through the glass panes and the breeder will no longer work.
Similar collision mechanics are used in other farms which would presumably be affected, too. For example, a common way to pacify a ghast is to push a glass block into its head, another collision that doesn't displace the ghast if it's confined. While I haven't tested this specifically, I have tested other mobs into whose heads I pushed a glass block, and they were displaced when I reloaded the world.
I have attached a world save that demonstrates this bug, but there are many additional configurations that exhibit it. The repro steps below therefore refer to the following menus of the known mobs and nonsolid blocks that can be used.
Mobs | Any mob that requires a 1 x 2 x 1 space to spawn. (I tested all but piglin, piglin brute, and wither skeleton.) |
Standing on | Glass pane with no side attachments |
Colliding with | Trapdoor, glass block, glass pane, bottom slab |
Steps to reproduce:
Build a 1 x 2 x 1 enclosure several blocks above the ground, leaving it open at the top and bottom. You can use glass blocks or panes in places for convenience, as long as the enclosure can keep a mob confined to the 1 x 1 space.
Place one of the Standing on blocks under the enclosure for a mob to stand on.
Spawn or summon one of the Mobs inside the enclosure.
Use a piston to push one of the Colliding with blocks into the mob's upper half. Or, if using a trapdoor, attach it to one of the blocks beside the mob's upper half, then fold it down over the mob's head.
Observe that the mob is not displaced by the collision. If you like, you can withdraw and replace the collision block several times to confirm that this behavior is predictable.
Save the world, then reload it. (Alternative: Use a Nether portal, then return.)
Expected result:
The mob is in the same position you left it in when you saved.
Actual result:
The mob has been displaced, usually downward through the block it was standing on.
(Results vary: Depending on the mob's collision box dimensions, a mob standing on a fence or wall might be displaced upward on top of a trapdoor or slab, or a mob standing on a brewing stand might be displaced downward into but not through the stand because the stand's base is too wide for it to slide past.)
Additional notes:
In the villager breeder, where two mobs are confined side by side, the usual displacement mode is a little different. Each of the mobs has a trapdoor closed over its head. Normally, a mob would collide with a closed trapdoor and wouldn't be able to be displaced into one from outside, but this bug causes one of the mobs to be displaced into the other mob's trapdoor. The second mob is then displaced downward by the combined collisions with the trapdoor and the first mob, and falls through the glass pane.
Related issues
relates to
Attachments
Comments


I attached a video showing how this bug can surprise the player. Here I set up the conditions for the bug to trigger when the chunks resumed ticking, but didn't trigger it right away. I teleported 1000 blocks away, then saved the world. The video shows what happened after I logged back in (still 1000 blocks away), then returned to the test jig. Immediately, the zombie gets displaced out of the enclosure.
[media]

Here are some isolated frames of the video that make more clear what happens in the test world.
First, the zombie glitches partially into the piston head:
Second, the zombie glitches back partially into the trapdoor:
Third, the zombie falls down behind the glass pane (notice the feet):

The story revealed by those frames may be informative, but it isn't essential to the bug. Normally when I test this I don't use pistons. Instead, the zombie's upper half is enclosed on 3 sides by solid blocks and the trapdoor is placed on the block behind it, then folded down. The only direction it can glitch in that configuration is downward, and so it does.

After further experiments, I find that upon reloading a world where a mob is standing on a glass pane or iron bars, it's unlikely to glitch through if the pane or bars are attached to an adjacent full solid block to the south. Attachments to blocks on any other side(s), in any combination, do not prevent glitching. I didn't test this with full rigor and suspect that this behavior might vary depending on the exact configuration of blocks constituting the test setup and/or the mob chosen.

I think this issue shares a common causal factor with MCPE-153431. Specifically, mob collision with blocks seems to be factored from the top of the world down. In the case of MCPE-153431, if the upper portion of a mob collides with a block while the mob is moving, then the game adjusts the mob's movement or position based on that collision before factoring any potential collision with a block at a lower Y coordinate. A similar process seems to occur in this bug when first loading a mob and the blocks around it into memory, which may perhaps be handled by the game as if the mob had just moved into its last saved position. That could explain why a block collision in the upper half of a mob causes it to glitch down through the block it is standing on.

There has been a change in how this bug behaves as of 1.19.50.22 Preview.
In 1.19.40, pushing one of the "colliding with" blocks into a mob left the mob embedded into the pushed block. Saving and reloading the chunk then caused the mob to glitch (be pushed) downward.
In 1.19.50.22, the new behavior is that pushing the block into a mob causes the mob to be pushed downward. This might mean Mojang has fixed the problem, since the behavior is the same whether or not you save and reload the world. However, I can't find anything about such a change in the 1.19.50 changelogs.

Auldrick: the change you're see in 1.19.50.22 Preview sounds like it could be related to this changelog statement:
When stuck inside a block, players will now be pushed towards the nearest open area
Although the changelog does not mention non-player mobs, the change may have been made to how all entities react to being inside of blocks.