The bug
Chunks can save some scheduled block update of other chunks in their TileTicks list which are then, once the chunk is loaded, performed too resulting in updates performed twice.
Comments on MC-711 might partwise be describing this bug.
How to reproduce
Create a superflat world with the following preset
minecraft:sandstone;minecraft:the_void;Set the render distance to 6
Run the following commands
/setworldspawn 100000 0 0 /teleport 110.5 1.0 0.5 /setblock 111 1 0 command_block{Command:"/teleport @p 0 ~ 0 -90 0"} /setblock 110 1 0 stone_button[facing=west] /setblock 110 1 1 dispenser[facing=south]{Items:[{Slot:0b,id:"stone",Count:2b}]}Press the button
Move in positive x-direction until you reach the blocks you placed before
→ ❌ The dispenser shot out two items
You might have to repeat the reproduction steps multiple times in case the chunk did not unload fast enough.
Code analysis
Based on 1.12.2 decompiled using MCP 9.40
The method net.minecraft.world.WorldServer.getPendingBlockUpdates(Chunk, boolean) creates a bounding box which is extended 2 blocks in the negative x- and z-directions.
It is unclear so far why this was done.
In 19w46b: (Mojang name) net.minecraft.world.level.ServerTickList.fetchTicksInChunk(ChunkPos, boolean, boolean)
Comments 4
I still cannot reproduce this anymore in 20w28a but as stated above, it would be good if a developer confirmed that the code behaves as intended.
I can reproduce this in 1.13, but can't in 19w46b. The method
ServerTickList.fetchTicksInChunkextends the bounding box by 2 blocks, however I am not familiar enough with the new chunk loading code to be able to tell if this method is actually called, or if aChunkTickListis used to write the pending ticks in which case the reproduction steps won't work.MC-165768 also makes reproducing this slightly harder.
I would like to leave the report open anyways since there is still this suspicious method.