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
relates to
Attachments
Comments


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.

Still a problem in 0.15.2

Still broken in 15.4.

Affects 0.15.10 & 0.15.90.8 (0.16.0 beta build 5).

Re-opening, as this was incorrectly closed as a dupe of MCPE-13983, which was a separate bug which has now been fixed. I have copied over the information provided by @unknown relating to this bug and added it to the description. Also revised the report title and attached the relevant screenshots from MCPE-17208 & MCPE-17274.

Revised title again, since this is not a bug exclusive to delays from repeaters, but delays from comparators, redstone torches, and other redstone delayers.

Now even worse in 1.1.0.0... previously, repeaters set to 1 rs tick delay seemed to have no delay compared to just redstone dust. Now, a repeater set to a 2 rs tick (4 game tick) delay also seems to have no delay compared to redstone dust. This breaks almost everything that relies on redstone timing. (And most contraptions were already having to use extra delay to ensure things were activated in the right order... now they need even more.)

Revised title yet again to be even more descriptive of the issue.

In 1.1.0.5, the behavior has reverted to what is was like pre-1.1.0.0... still broken, but less broken. 😛

I can't confirmed on 1.2.1.1.
Probably fixed.

^ Still occurring in 1.2.1.1. How did you test this?

MaladjustedPlatypus
[media] I tested this way.
But, Re-affected on 1.2.2.

@r.takahashi Although the pistons are clearly getting pulsed at the same time, if you look closely you can see that the redstone dust next to the repeater is being activated 1 tick after the piston.

Still affects in 1.2.5.13

I can confirm this is still happening as of 1.2.5 build 2 on Windows 10. Pistons appear to be slightly faster than before, but that didn't fix this bug (though it may make working around the bug in contraptions a little easier).

Still affects in 1.2.6.2.

I originally posted this to [MCPE-25360] but I think it belongs here more
I captured this behavior today in slow-mo with the help of a
[media](Uses AutoHotkey v1.1; run then press ALT+k to activate). The
[media]contains 10 images, 5 covering the rising edge and 5 covering the falling edge, representing 0.005 second intervals beginning with 0.005 seconds after clicking the lever. Due to issues with Windows not saving screenshots, images were captured individually on sequential runs.
[media]

Can anyone prove if this happens to moving observer blocks?
Edit: I'm going to try my hand at it Sorry, what I'm thinking of is probably a different issue

Still affects in 1.2.10.2.

I built a monostable circuit and placed a repeater in front of it. It should have given me a short impulse but it didn't give me anything at all.
[media]
Steps :
1. Place a block and a redstone dust on it.
2. Place a sticky piston vertically and a block on it.
3. Place a block and a repeater on it.
4. Place a block and a repeater on it before the redstone dust already placed.
5. Active with a lever or a button, it won't work as expected.
Watch the video included if you don't understand.

Affects 1.4.0.5

This has been around since repeaters were added and that was in 0.14.0. We are now in 1.4.2 and approaching 1.5

@unknown, Please do not make comments like that, they are not helpful in getting the issue resolved any faster. Thanks.

Okay, sorry about that then🙂

I did some testing on this using the same design in 9 separate locations to make sure there wasn't any other factor in play. I put a lime concrete block on the ones that were following the intended behavior and red on the others over 2 consecutive runs:
[media]
Still affects 1.6.0.6

This is also affecting the Xbox one Bedrock version as of the Sept. 17 of 2018 in the most recent update. Please fix this or tell us if this is an intentional thing.

[Redacted: May have been inside information that Mojang does not want shared at this time.]
For the present, the workaround of inserting a dummy repeater on input signal lines pulsed by world events is often enough to ensure the behavior of the circuit is at least predictable.

Source? ^

There is still a problem with the monostable circuits

Affects 1.11.0.1 beta version

Affects 1.11.0.3 beta version

Please remember that the bug tracker is for reporting bugs only. It is not a discussion forum or a feedback site.

Affects 1.11.4

Affects 1.12.1

I think this is related but with observers this time.
I built a flying machine only with sticky pistons and it should work (or at least, I think so). Just look in the attached files to see what happens.
Sorry if this is not related.

My concern is that if I create redstone contraptions now, and design them to work in spite of this bug, they may break when this bug is fixed. Please fix this ASAP so players can make contraptions that will continue to work in the future.

Affects version 1.14.60.

Observers showing up to a 3 tick (often randomized) delay on 1.14.60.

Affects 1.16.0.63

(note: different types of components are powered in alternating gameticks, it may be useful to know to understand why it happens)
This seems hard to fix without major changes to redstone.
The issue isn't with the repeater. The issue is that when a world change happens, the components activated in that tick (often called consumers) aren't instantly powered/depowered.
You can either:
remove the delay and make chains of pistons instantly power/depower each other
add extra delay to repeaters from world changes (and other components known as producers)
fix it only for player interactions
The first two would break most redstone builds. The third wouldn't, but doesn't really fix the bug fully.
May I suggest that this is marked as "Won't fix"?

Affects 1.16.40 Hotfix.
Affects 1.16.100.55 Beta.

Affects 1.16.100.56 Beta.

Affects 1.16.100
Affects 1.16.200.56 Beta

From MCPE-103999:
[media]In the first video, the piston should extend/be powered like the repeater and redstone dust, but doesn't because it is processed in a different tick ("consumer" tick)
[media]In the second video, the piston is powered, but the repeater is not, and the dust is VISUALLY not powered, because they are processed in a different tick ("producer" tick)
In both situations, the wire, repeater and piston should, logically, all be powered.
This behavior is not only inconsistent with java, it is also very unintuitive. It makes no sense to behave this way.

Still in 1.19.2and 1.19.20.20

1.19.20 too

Still affects 1.19.63

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.