Player placed leaves decaying

I have a similar problem. Leaves placed on a structure keep disappearing. I placed string on the top and sides of the leaf blocks (I thought maybe lightning was striking the leaves, but never saw this actually happen, and someone said string protects against lightning) but this didn't help. I also replaced the layer of blocks under the leaves with logs, hoping this would prevent the leaves from despawning. But they are still disappearing with no explanation.

Confirmed in 1.14.60 Hotfix on Windows 10.

Steps to reproduce:
I have attached a demo world, "Despawning leaves.mcworld". If using it, skip to step 4.

1. Create a flat world in Creative mode with Random Tick Speed set to 50. Load it.

2. Float up into the air somewhere near the origin.

3. Use the command /fill -16 4 -16 15 4 15 leaves 0.

4. Wait a few seconds to verify that the leaves are not going to despawn.

5. Break any leaves block.

Expected result:
The remaining leaves do not despawn.

Actual result:
The remaining leaves begin to despawn as they receive random ticks, until they're all gone.

Use leaves 8 to place persistent leaves with commands

Well, I can't seem to reproduce this on 1.16.40 (iOS). A player-placed oak leaves block has a data value of 12, which means it does check for nearby wood logs but doesn't decay according to the Wiki page: https://minecraft.gamepedia.com/Leaves
No idea what's the point of checking for nearby wood, if they are marked as non-decaying, but anyway all of my player-placed leaf blocks survived for more than 15 minutes under tick speed of 1000.

After a conversation with another staff, we concluded that:

• Manually placed leaf blocks don't decay, at least on 1.16.x. This is an expected behavior.

• Leaf blocks placed with /setblock or /fill decay by default, unless the data value of 8-11 (persistent_bit being set) is also specified. This behavior is questionable.

• 0-3 being translated as persistent_bit being false (i.e. decaying) can either be a bug or a bad decision. Command-placed leaves shouldn't decay by default in our opinion.

• Using 4-7 (only update_bit being set) makes leaves decay right away as expected, because they will search for wood logs on the next update which happens immediately after the placement.

• Using 12-15 (both persistent_bit and update_bit being set) also makes them non-decaying as expected but there's no reason why a player would want to do that. The game doesn't check for logs, for a good reason, if persistent_bit is set regardless of whether update_bit is also set.

After further study, I found out that my reproduction of the problem reproduced the symptoms because I placed leaves using a /fill command with the data value 0. To get non-decaying leaves using a command, the data value should be as follows:

Initially, I assumed you had placed leaves that you obtained from creative inventory or by using shears or a hoe on naturally generated leaves. But my investigation showed me that leaves obtained this way are not eligible to decay. Even if you obtained them with a silk touch tool, they would lose their decay eligibility when they entered your inventory. So I was stumped as to how you could have placed leaves that were eligible to decay...unless you used a command.

Commands are meant to go beyond the limits of what a regular player can do. As such, when you use a command you have to specify additional data that isn't normally visible to a player. This additional data is specified in the <data> parameter of commands, and the valid values can be looked up on the wiki. In the case of leaves, the wiki isn't very clear on what the data values mean, except for the species of tree it belongs to, but data value 0, the default if you don't specify a <data> parameter, is generally a sort of archetype for the block. And in keeping with this, data value 0 for leaves corresponds to oak leaves.

Unfortunately, for leaves the data values 0–3 are for leaves that are eligible to decay, and it's pretty hard to get that fact from the wiki. You'll almost never want to use those values in a command that creates leaves, and instead should use the values 8–11, which are not eligible.

Of course, this is only the explanation for your problem if you did, in fact, place the leaves with a command. Please confirm that you did.

If you didn't, there's one other way this could have happened. We used to have a bug (back in 1.12 I think) that would retain too much information from certain things you mined with silk touch. One of those things was leaves, and the bug caused them to retain their decay eligibility when they should have lost that. I'm not sure this is a satisfactory explanation because there were several opportunities for the game to correct that error as you moved them from storage to your inventory, but if you did it a certain precise way it's possible the error would persist and the leaves would remain decay eligible. Please comment on whether you might have collected the decaying leaves by mining them with a silk touch tool a long time ago.

I'm closing this ticket temporarily pending your response. It will reopen automatically when you reply.

Cleaning up old tickets: This ticket had been set to 'Awaiting Response', but has not received a response from the reporter (~3 months+) so is being closed as Incomplete. If you feel this is still a valid issue then please comment, or create a new ticket following the Issue Guidelines which includes steps to reproduce the problem.

Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki

I've had the exact same issue.  I've coved the entire farm in string, but instead of despawning down at the tower the leaves are despawning up at the afk platform, which causes me to die nearly every time i've gone afk over the past day, which also results in a loss of all my items.  I'm not sure if its because I silk touched the leaves that im using at the top, rather than the sheers that I used at the bottom, but I still personally feel like that shouldn't make a difference.  Please help me out here.