MC-279339Update order for sloped rails is incorrect
Since 1.18 it has been established that the expected behaviour for rails and their neighbour updates should always be in the order of the furthest rail from the power source sending neighbour updates to surrounding redstone components first. However snapshot 25w02a has introduced a different behaviour for configurations of rail where there is a slope. In this case the rail at the top of the slope updates first and the sloped rail below is updated second despite being further from the power source.
The attached sceenshot gives a simple test setup demonstrating the problem.
Expected behaviour: 
the command blocks execute their commands in the order 1,2
Observed behaviour: 
the command blocks execute their commands in the order 2,1
Linked Issues
Created Issue:
Update order for sloped rails is incorrect
Since 1.18 it has been established that the expected behaviour for rails and their neighbour updates should always be in the order of the furthest rail from the power source sending neighbour updates to surrounding redstone components first. However snapshot 25w02a has introduced a different behaviour for configurations of rail where there is a slope. In this case the rail at the top of the slope updates first and the sloped rail below is updated second despite being further from the power source.
The attached sceenshot gives a simple test setup demonstrating the problem.
Expected behaviour:
Observed behaviour:
Attachments1
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
![[Mojang] Triage Team](../../../data/avatars/users/89842.png){kind=small}
Important![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[MCQA] v-kkunytskyi](../../../data/avatars/users/93751.png){kind=small}
![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
[Mojang] Gnembon![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
Can confirm.
This bug is caused by the updates now in baseRailBlock affectNeighborsAfterRemoval no longer getting called whenever powered/activator rails change state due to changes in how levelChunk setBlockState works
The old update order is:
Block updates around 1 block above (if sloped), Block updates around rail, Block updates 1 block below, - from what is now in affectNeighborsAfterRemoval
Block updates around rail [not usually observed], Shape updates around rail - from level setBlock with flag 3
Block updates around 1 block below; Block updates around 1 block above (if sloped) - from poweredRailBlock updateState [both not usually observed]
The 25w02a update order is:
Block updates around rail, Shape updates around rail - from level setBlock with flag 3
Block updates around 1 block below; Block updates around 1 block above (if sloped) - from poweredRailBlock updateState
The fix should ideally result in the following order: (Assuming the 2nd set of updates is not useful which I do not recall it is)
Block updates around 1 block above (if sloped), Block updates around rail, Block updates around 1 block below followed by Shape updates
If the 2nd set of updates do matter, then refer to the old update order detailed above.
[For image: Lowest is cmd block 1, Highest cmd block is 3; Expected is 3, 2, 1]
The redstone torch updates got changed too for the same reason, and there are possibly more affected blocks.
Hi!
Could you please record and upload a video of this issue?
Also please add reproduction steps as follows:
Steps to Reproduce:
Observed Results:
(Briefly describe what happens)
Expected Results:
(Briefly describe what should happen)
This ticket will automatically reopen when you reply.
Video:
Bug.mp4
How to Reproduce:
• Build the setup shown in the video/images, place 3 command blocks with the following commands:
Say
Say 2
Say 1
• Activate the command block with the command (say)
Expected and Observed behaviour:
Expectations: The order should be 1 then 2 in chat
Observations: The order is 2 then 1 in chat