Strange nondeterminism in horizontal hopper pipes and their cooldown counter

While experimenting with the "item counter" shown below, I found another strange phenomenon which is very likely to be tied to the issue.

This "counter" transfers items in the chest Ca to Cb with emitting 4 tick on-pulse for each single item passes through it... at least in theory. Every time the hopper Ha receives an item, it suspends the hopper Hb until Ha pushes the item into Cb and becomes empty.

I put 64 items into Ca and observed the pulses it emits. The result was very surprising. The first item stayed for 8 game ticks (4 redstone ticks) in Ha as expected. But things started to go mad after that. For the 2nd to the 64th items, they either

1. Stayed for only 1 redstone tick in Ha, or

2. Teleported from Hb to Cb without any observable delay.

Both cases are glitchy because every time Hb pushes an item to Ha, it should reset the cooldown counter of both Hb and Ha to 8 so the items should always stay in Ha for 8 game ticks. The only difference between the first item and the rest is that whether the cooldown counter of Ha is 0 or 2 (not 4 due to MCPE-12848). So it might be that Hb was resetting the counter of Ha only when it was 0, which was the source of the problem.

I confirm the hoppers don't perform reliable on the iOS 0.14.1 version. If you put items in a chain of hoppers, it seems some hoppers are skipped (if you keep monitoring them, no items seem to flow through. seemingly they jump to the end hopper immediately). I experimented with several item sorters, and of a full stack of items only the first item is sucked into the hopper below, the rest moves on. I build a loop of hoppers in an item sorting system and first I thought every loop it would suck one item in the hopper below, but doing several test runs, the results were everytime different and therefor could not be reproduced reliable. The more items are in the hoppers, the worse it gets. I also tried a huge sorting system, with the same item in every hopper below the main chain of hoppers, hoping that every hopper would suck 1 item of the stack, but again only the first hopper would suck 1 item and the rest would pass over all the other hoppers. Unable to reproduce reliable test results, gives me the feeling it is a multithreaded part of the code. Hope it helps.

I believe several reported issues are related to this problem or are duplicates

Yes, it was a tiled set of item sorters that made me aware of this unreliability. I suspect that they changed the "push" action of hoppers so that source hoppers reset the cooldown counter of destination hoppers only when the latter is zero in order to work around MCPE-13417. It's true MCPE-13417 can be "fixed" that way but it's a wrong thing to do, and that resulted in this glitch. The correct behavior of a hopper would be to:

1. Decrement its cooldown counter if it's non-zero.

2. Check if it's disabled (i.e. being powered or adjacent to a powered solid opaque). If so, wait for the next game tick and return to the step one.

3. Check if it can suck item entities above it. If so, suck them all at once regardless of the cooldown counter (MCPE-13891).

4. Check if its cooldown counter is zero. If not, wait for the next game tick and return to the step one.

5. Check if it can push an item to the destination. If so, push it and reset its own counter to 8. And if the destination is another hopper, reset the destination's counter to 8 as well.

6. Check if it can pull an item from a container above. If so, pull it and reset its own counter to 8. (Do nothing special even if the container in question is in fact another hopper.)

7. Wait for the next game tick and return to the step one.

And it's very important to follow all of these steps atomically. If two hoppers were doing these in an interleaved way, they would end up in this nondeterminism, e.g. hoppers whose counter is reset to 8 may continue to push/pull items due to a race condition. Of course you cannot use pessimistic locking to synchronize hoppers because that would result in a dead lock when there is a hopper loop.

(As a side note, some people believe that hoppers pull before push but I think that's incorrect. If in doubt, try placing a single hopper pointing sideways and use two chests as an input and output. If hoppers pull then push in the same game tick, you can't observe items passing through the hopper by measuring with a comparator or watching its inventory.)

Confirmed: iPad v0.14.3

Confirmed this to still be an issue in 0.15.0. This breaks all manners of the way hoppers are supposed to deliver items based on the "tick".

confirmed for 0.15.10- hopper item sorters are unreliable because sometimes they do not pull in items properly. Also with 2 hoppers facing each other, and multiple items, it should theoretically send 1 item back and forth however sometimes an extra one is pushed seemingly randomly

Still an issue in 0.16

Confirmed still an issue in Windows 10 Edition 0.16.0.
In the similar arrangement shown in the 3rd attachment image, items placed in the top chest will all end up in the bottom chest. Items placed in the chest on the left side end up about 60/40 in the bottom and right chests respectively. I found I can get it to behave properly by disabling the left hopper 5 ticks out of 6.

Still a problem in Windows 10 edition 1.0.0.

I finally found and fixed the issue. It will be available soon (tm).