pwouik

I suggest rounding the random angle to like 1/100 of a circle, that should avoid these cases and make it possible to exhaustively check contraptions, without breaking float alignment
the actual problem here is that it is extremely rare event that doesn’t happen in a reasonable reliability test

still in 1.19.1 rc2,
in PoweredRails.updateState and BaseRailBlock.onRemove for rails
onPlace and onRemove for redstone torches
same for button and lever

@Spottedleaf
the order is still DFS, the stack is just on the heap, and updates from an update are collected and put on the stack, then executed. this change the order of state updates vs block updates,but not block updates themselves

This bug is due to the piston code that read from a hash map when removing leftover blocks after creating moving blocks

@GamerPro08 this is intended, pushing an observer doesn't keep the cooldown

happen with lag,the server probably try to place in 2 different tick an fail for the second but the client place them before the server send the blockevent

redstone dust update 2 blocks away and update the first redstone lamp and schedule a tiletick early,like this:MC-189954 but with a lamp

same as this:MC-137127

the button depowering is not a player input but a tile an behave differently than a player input

the redstone now light in 1.17.1 because of this fix:
MC-213986
Whether a piston attached pulse or not depend on the dust update order:
MC-11193

same issue with observers:MC-137127
also it doesn't send state updates,and will not redirect a redstone dust
idk if this is why observer dont pulse when pushed while powered,that is commonly used
but there's probably some contraptions that depend on this

fixed in 1.17.1pre1 I think

test with a mod I made that fix rails with about 320 blinking rails: 17 mspt to 10.5 mspt

note that rails are widely used in farms to avoid the lag from redstone dust

a solution could be comparing the tick of creation with the current tick because it's synced with the server tick and wont be affected by how many times the client tick

this bug happen when a blockevent try to push a moving block in the 1st or 2nd tick

here is some setup that make it more clear,trying to push at the 2nd tick:

The reason is in PistonMovingBlockEntity.java (mojang mappings)

if the client dont receive a packet to turn the moving block back into a block,the block entity progress of the moving block will still increase clientside but the animation stop and a counter: "deathTicks" will increase

when it go over 5,the moving block block turn into a block clientside and remove the blockentity,so the block can be pushed clientside and create a ghost block

this can happen if there is a server side lagspike and the client can execute about 7~8 ticks before the next server tick

a solution could be raising that "deathTicks" limit, or removing it (I dont know the the effects, it could leave some glitched extending pistons when players have a bad internet conection, EDIT:bad idea, moved ghost blocks will just get stuck,they are already stuck for 6 tick after moving)

this is a normal behaviour,in the row in front of the piston,the last block that updates the piston is the one just in front,and the last block the turn into a block is the last of the row,so that will happen if you have 2 block directly in front of the piston and you repower it before it fully retracted.This is used in many bud switches and other contraptions