Hopper interaction is dependent on order of placement, and may break when reloading chunk

Is this still an issue in the most recent versions (currently that is 1.12.2, or the latest 1.13 development snapshot 18w07c) of Minecraft?

Confirmed for 1.13.1.

Still an issue in 1.16.4, seemingly irregardless of orientation, chunk borders etc.; breaking and replacing glitched hoppers will sometimes fix it until reloading the area.

The underlying problem might be that block entities are ticked in the order in which they have been placed (until a reload of the world).

@marcono1234 Can't rule it out entirely, but I'd doubt it. Hopper lines are almost always placed in the same order from finish to start, if placing order mattered, hoppers should either consistently malfunction or all work flawlessly. It also wouldn't really explain why breaking and replacing the same line of hoppers in the same order and place fixes it (should have been more specific in my last comment - I don't only replace the glitched hopper, but the whole row of hoppers).

I'm not sure if it's necesssary or helpful, but here's my description of the problem (including more detailed screenshots):

Setup: Build a line of hoppers with droppers pointing into them. Droppers carry individual items and are fired at the same time. Hoppers were built from right to left / from finish to start, in case placing order matters. [1st screenshot]

Expected result: Items should arrive in the chest in order from right to left, e.g. Iron Nugget, Iron Ingot, Iron Block. Working as intended after building and pressing the button. [2nd screenshot]

Restart the game. Moving far away from the hopper line to unload it also works. [3rd screenshot]

Press the button again, items have now switched order - the iron block got ahead of the iron ingot. [4th screenshot]

Offending hopper: The hopper above the iron nugget dropper contains an iron ingot in the 2nd slot after having moved the iron nugget into the next hopper. Notice there is no instance in which this hopper contains both the iron nugget in the first slot and the iron ingot in the second slot, but behaves as if the iron ingot was pushed in just before the iron nugget went into the next hopper, thus placing the ingot in the 2nd slot. Tested via CarpetMod /tick freeze, advancing one tick at a time. [5th screenshot]

7 ticks later: The same hopper now contains both the iron block as well as the iron ingot - again suggesting that the hopper on the left pushed its item (the iron block) just before the iron ingot could be pushed forward. [6th screenshot]

1 tick later: On the very next game tick, the iron block is pushed forward into the next hopper, skipping ahead of the iron ingot and resulting in the wrong outcome item order.

-> It seems like the third hopper (above the iron nugget dropper) starts to fall behind after relogging, not being able to push out its item (nugget) before receiving a new one (ingot) from the hopper behind it. This results in the new item (ingot) being placed in the second hopper slot, as well as on the next push allowing the third item (block) to not only be placed in the first slot, but also basically skipping the hopper as it travels right on to the next hopper within the same game tick.

Further observations from testing:

• Even when advancing time tick by tick, it's not always possible to see 2 items in a single hopper at the same time; instead, the hopper will keep its item in the second slot while the next item skips this hopper entirely in a single tick.

• Building the same machine in different locations and/or with different orientation will sometimes result in different hoppers malfunctioning.

• First building the hopper line or replacing the hopper line will always result in the correct item output order, while relogging seems to always result in a bugged hopper, and it's always the same hopper. Instead of replacing the whole hopper line, replacing the offending hopper (e.g. the one that receives an item in its second slot) as well as replacing the hopper pushing into it seems to always fix it.

• Item teleportation: In another test with 5 droppers, relogging resulted in 4 of the hoppers being glitched (having their item in the 2nd slot). Just before the next hopper cooldown expires, the hopper above the gold ingot dropper contains a gold block ready to be pushed [7th screenshot]. On the very next tick, the block is teleported into the last hopper in the row, completely skipping 3 hoppers in between. [8th screenshot]

[PS: Any way to make the screenshots smaller / hide them in a spoiler tab?]

Thank you for your response as well as the formatting tips! Just to quickly confirm - the bug persists also when starting the unmodded vanilla version from the launcher (I didn't uninstall the mods before testing, but I assume simply starting the unmodded installation should suffice).

Also, thinking more about it, I believe I was a little quick in ruling out placement order / loading order as a possible cause - when placing the hopper line from first to last (e.g. placing hoppers against temporary blocks from left to right instead of placing hoppers pointing into the chest / next hopper), the items seem to come out consistently in the wrong order. Similarly, replacing the hoppers via /fill command only fixes the issue when the hopper pointing into the chest is placed before the hoppers pointing into it.

I'm not familiar with how exactly loading chunks / blocks in chunks works in Minecraft, but assuming it follows certain rules - e.g. loading a whole chunk at once or loading blocks in a chunk in a certain order (such as north-west to south-east), shouldn't placing the machine in different orientations produce different results, or even force the game to load the hoppers in the correct order to not produce this bug in one orientation?

It appears block entities are stored and loaded in arbitrary order, however that order is consistent as long as the number of block entities in that chunk does not change see method LevelChunk.registerAllBlockEntitiesAfterLevelLoad()).
However, I am not very familiar with chunk loading either, so this analysis could be incorrect.

That would imply that adding a lot of block entities to a chunk might yield different behavior after reloading the chunk. Or maybe even placing the structure with the same orientation in a different chunk could have different behavior.

This bug is related to the way in which hoppers are assigned to the tile entity list when a chunk is loaded. If you place hoppers in the world in a specific order they are added to the list in that order and as such will execute their tasks of pulling and pushing items in the order governed by that list. When the chunk is unloaded the hoppers are not saved in a list which maintains their order, instead the game uses a hash set which obsfucates the order of the hoppers upon loading the chunk from memory. This hash set is slightly more efficient in terms of memory usage than an ordered set, however causes all kinds of ambiguous behaviours which vary depedent on a hoppers position in the world.

This hash set obsfucating the order of hoppers therefore results in contraptions which rely on the order in which hoppers pull and push items locational and break in ways which would be very confusing to the player. I know of a particular mechanism for detecting when a shulker box is full and replacing it with a new, empty box. This mechanism works perfectly fine in most locations and so when designing an entire storage system based upon it I simply built a single setup and stress tested it for hours finding no issues. But then when I copied and stacked the mechanism 350 times to make a storage system capable of storing items in shulker boxes. A bunch of the box loaders kept breaking and it drove me insane trying to figure out the cause. Eventually I had to do a range of testing, swapping the order of the hoppers to find that the exact reason was the locationality of hopper hashing messing with the order of items being pushed and pulled through the overflow detection of the box loader.

Random mechanics like this that are extremely technical and difficult for the basic player to understand and really depreciate the quality of the game, making the technical aspects of redstone less acessible to the general playerbase as they run into issues they don't understand. Giving the player more control over how game mechanics interact instead of introduces randomness that causes stress should be an important consideration for the development of this game.

Wish we could get an explanation as to why this won't be fixed. It seems like the developers are trying to make redstone more accessible given all the recent additions in 1.19.4 and the 1.20 snapshots, yet longstanding features like hoppers and redstone dust are still non-deterministic and locational (MC-11193). The behavior discussed in this report only exacerbates the problem, and, to reiterate cubicmetre's comment, makes redstone more frustrating and unapproachable for folks unaware of these quirks. I'm certain that I'm not alone in thinking this - as indicated by the duplicate reports, it's easy to accidentally create a hopper setup that behaves differently after a reload.

Resolving non-deterministic behavior is a completely separate issue, but at the very least I'd hope that this ticket is reopened and the problem corrected if there are no plans to fix hopper locationality any time soon. Perhaps there is some way to insert tile entities into the HashSet upon placement instead of upon unloading, which would fix this problem as I understand it. Either way, I don't think these kinds of issues should be ignored, if not for the sake of more consistent redstone builds then for a slightly less steep redstone learning curve.

Also in 1.21.1