The Bug
When you send pulses into arrays of repeaters in quick succession, they will be lost.
How To Reproduce
Build setup as seen on picture
[media]
Push the button
→ ❌ Notice how the signal travel through all the repeaters but the last one.
(Note: this description uses “redstone ticks”, which are actually 2 game ticks long.)
Note: It does not matter how long the array of repeaters is, you could have 500 and the last one would fail to turn off. This might have to do with updates, but when working with complicated or fast timing circuits, this bug is very annoying.
On the right setup, a 1 tick pulse is generated when you place a redstone torch on the redstone block. It should give a 1 tick pulse to the piston, then turn off for 1 tick, and then give another 1 tick pulse. Instead, it gives a single 3 tick pulse.
This is the most annoying of all when you have a large (downward) piston extender which can only be powered from one side, because you have to use redstone lines and to BUD a piston below another one, you have to send 2 pulses with 1 tick of delay inbetween.
Code analysis
Based on 1.11 decompiled using MCP 9.35 rc1
The reason why the last repeater or comparator stays powered seems to be that the methods net.minecraft.block.BlockRedstoneDiode.updateState(World, BlockPos, IBlockState)
and net.minecraft.block.BlockRedstoneComparator.updateState(World, BlockPos, IBlockState)
set a different priority for the update based on whether or not a repeater or comparator is after them.
—
Newer code analysis by @unknown foundin this comment.
Linked issues
is duplicated by 26
relates to 1
Attachments
Comments 83
Just try out one of the setups 🙂

How very odd. Hit the button on Pulsetest 1, and each of the repeaters will go out for a moment, except for the last one. It doesn't matter how many repeaters there are, as long as there's more than one. The last one in the chain will stay solid.
However, if you put a redstone torch on top of the redstone block in Pulsetest 2, each of the repeaters will light up for a moment, including the final one in the chain.
left setup confirmed, right setup piston needs a redstone tick or 2 to extend, 50% confirmed 50% intended
Yeah this one got in the way of me too in the past. For reference here's Dico's video on it:
https://www.youtube.com/watch?v=aeroMoWIN34#t=159
I've made a video on it myself a while ago, basically saying the same but adding that adding wires to the same circuit will fix this behavior.
Still an issue in snapshot 21w03a
Can confirm in 21w05b.
Still an issue in 1.17.1

That is a good point, Lukas Fink (this comment). I think the primary concern was that you can get something similar to the chain bug, if you have a comparator chain facing into a single comparator on subtract mode. If you have a quick off-pulse through that chain, you would end up with the chain bug at the last comparator:
[media]The concept of the solution to the chain bug is simple. The priority for any diode turning off must to be lower than or equal (meaning processed first) to the priority of any diode turning on in a chain. Thus, we had to change it to fix the abovementioned issue.

Affects 1.20.1.
I don't really get what you're trying to say