What I expected to happen was...
On flicking the power switch in each example, the blue example shown would fire like the red example shown (end repeater lights up).
What actually happened was...
In the blue example, the output repeater doesn't fire. If you rapidly flick the switch back and forth, the blue repeater fires intermittently.
Steps to reproduce:
Drive redstone current into a block on top of a piston to generate a 1-tick pulse (red example). Position a repeater to pick up the current from the piston block, but the redstone should flow directly from power source to the block.
Turn on the power source; the piston will fire and the output repeater will light up for its pulse duration.
Insert a repeater anywhere along the input line and toggle the power source. the output repeater will not fire.
Rapidly toggle the power source (switch works best). The repeater will occasionally fire.
replacing the relay with redstone torch inverters shows the same issue (the mechanism will fire when the torch is placed, but not when the mechanism is toggled).
Using an observer block as the power source showed the same issue.
Minecraft pocket edition 0.15.0 (iOS - replicated on iPhone 6 and iPad air 2)
Update by @unknown
This bug has been reported to our internal bug tracker for further testing and a fix. It is scheduled to be fixed in one of the future updates (no specific date can be provided).
Please avoid duplicate comments. Post only NEW information regarding this bug.
Update by @unknown, explaining the cause of the bug
Repeaters don't apply the delay properly in all cases. If the repeater was activated by another pure redstone component being ticked, then the delay will be correct. However, if it was activated by a world change (lever, piston modifying a circuit, pressure plates, buttons, etc) then the repeater will output a signal 1 tick too fast. A 1-delay repeater will act as a 0-delay repeater (that is, completely ignored). A 3-delay repeater will act as a 2-delay repeater.
Linked issues
is duplicated by 38
MCPE-103691
Repeaters are not applying correct delay and appear as though they do
Resolved
MCPE-103999
Redstone components do not react based on the game tick power is provided
Resolved
MCPE-136762
If a repeater runs into a monostable it won't work
Resolved
MCPE-161802
Circuit breaker pulse limiter does not function properly when receiving input from repeaters, redstone torches, observers, or comparators
Resolved
MCPE-167483
Disappearing signal delay / repeater affects downstream timings
Resolved
relates to 7
MCPE-37479
Command blocks fail to recognize their power state changed for 3 ticks
Open
MCPE-12848
Comparators measuring a container take redstone 2 ticks to change their state instead of 1
Resolved
MCPE-89921
Observers dont activate redstone dust and repeaters when it is pushed by a sticky piston and that sticky piston gets powered by another observer
Reopened
MCPE-22741
Fill command doesn't give repeater the correct delay
Resolved
MCPE-24278
inconsistent Redstone/pistons
Resolved
Attachments
Comments 55
I had something similar. I was working on an automated melon farm using the observer block. I had the farm working correctly last night, and when I looked at it today, two of the repeaters in the circuit would not activate. I removed the repeaters and put down two new ones and the circuit began to work again.
I was testing this on a Windows 10 Edition. I can attach a download of the world if you need it.
I can confirm that driving the last stage of your input chain with a redstone block on a piston does work as a fix (with as many relays running into the redstone block piston as you need). This leads me to believe it's a problem with the way piston timing and redstone timings interact.
Given that this is still an issue years later, I would really appreciate some official commentary/explanation of the underlying issue.
On the surface, this seems incredibly straightforward to fix without major changes to tick processing order. That is, simply have components remember their previous power state, and always queue an update to invert them during the next tick if they received any update that would have changed their state during the previous tick. I.e. This should just require adding a flag(s) to tile entities and an additional step to the block update logic). Maybe I'm wrong, and this would break other things, or harm performance more significantly than I think. And of course, I can think of other (potentially noncompatible) ways to address it.
In either case, a specific, techically comprehensive, explanation of this years-old and wildly frustrating bug would help set expectations for how this will be managed in the future, and what impact it will have on our clumsy workaround designs when it is eventually fixed.
About redstone timings in Bedrock Edition
Here's an article about techically comprehensive explanation of redstone in Bedrock Edition, which may be helpful to understand why these issues happen.
In Bedrock Edition, redstone circuits rely on the circuit system to work, rather than block updates. The fundamental reason for these issues is that there is something wrong with the original design of the circuit system. To fix the bug, many disruptive changes must be made, and perhaps even needs rewrite the whole circuit system. That's why this frustrating bug can't be fixed for a long time.
This problem often affects mechanisms designed for tick, because of it I face the fact that the mechanisms do not work correctly and constantly break, which makes their use in the game impossible
In the video, the mechanism should go down 1 block, but because of the different delay of the signal given by the observer, it often works incorrectly or breaks https://youtu.be/fOfB7Tgd_gA Unlike Java, in Bedrock the mechanism works differently every time you run it and it's quite annoying
Interesting. It is possible that this one and MCPE-15607 stem from the same root cause.