Triton365

That's true for checking items, but /clear is still necessary when actually removing items from an inventory. (I didn't include that in the reproduction setup because I thought constantly clearing and refilling items might bias the benchmark.) Using it with execute store result to get a numerical value for item amount is also common, though that's at least easier to work around now with if items.

Also, no worries! There was a hint on the Minecraft Commands Discord that a fix might actually be possible. It's not guaranteed yet, but it seems promising.

Thanks for confirming!

1. What counts as 'actual impact' is a bit tricky here. People who are aware of this issue would end up moving to more complex workarounds just to avoid using /clear in their datapacks, and those who don't know about it would be left with a mysterious performance degradation that triggers whenever they do something in creative.

2. If you are referring to the 1024 repetitions, that is not a strict requirement to trigger the bug. It was just used as an example to make the performance difference clearly visible. Even if these commands aren't run in an artificial loop like that and are instead spread across various things, they are still affected. The main point is that this is an abnormal increase of lag, and less lag is always better.
   /clear is widely used for implementing basic mechanics like detecting items, consuming arrows/resources, or banning illegal items. The more features like this a project has, the worse the impact gets. Multiplied checks from using the "@a" selector with multiple players is also a contributing factor.

Let me put this in a programming perspective. What would be the value of f in the following code?

float f = 8.0;
f = 1.1;

According to the IEEE 754 standard, the value of f must be exactly 1.10000002384185791015625, which is the closest representable number to "1.1". It should never result in 1.099999904632568359375(“1.0999999“) or 1.1000003814697265625(“1.1000004”). This is exactly what I am pointing out as a bug in this report.

Also, this is a simple assignment. The previous value 8.0 should have absolutely no influence on the subsequent assignment. Another key point of this report is that the entity's previous rotation is incorrectly bleeding into the new value during a /rotate command, which should behave as a clean assignment of the target coordinate.

Furthermore, it is important to note that this is a regression first observed in snapshot 25w32a. It worked correctly in previous versions, proving this is an issue with the game's implementation rather than an inherent limitation of the IEEE 754 standard.

Fixed in 25w32a update.

This was discovered while testing the bug MC-277661. That issue appears to have been fixed in 25w32a (although it's not mentioned in the changelog), and this behavior is occurring instead.

Huh… this is too weird to be WAI.

A possible explanation for this issue is that the both the first creation of the execution context and the as subcommand did a shallow copy when copying player’s position, which was affected by the subsequent teleportation, but is this really the official opinion of Mojang? It's very strange that the developers would expect the user to understand this distinction between shallow and deep copies that occur internally in each subcommand.

I was a bit confused after reading that report, but I think I understand the difference between these bugs, so let me clarify.

It seems like MC-270134 is describing that set_count function does not allow overstacked items, and my report (MC-277803) is describing that set_components function does not allow overstacked items. The commands in MC-270134 are actually working fine in current release (1.21.3), so the set_count issue is fixed now, but the same issue is still present in set_components function.

I see that changing the order of the functions fixes this as well, but there are cases where you can't change the order, like this command.

/loot give @s loot {pools:[{rolls:1,entries:[{type:loot_table,value:"blocks/redstone_ore",functions:[{function:set_components,components:{max_stack_size:1}}]}]}]}

So I think this could be considered a valid bug.

You can reproduce it with just the commands in the description, the loot tables are defined inline.

Open a singleplayer world with cheats allowed and run the commands in chat. When you run the latter command, you'll see the set_components function fail to apply (expected to get 2 stacks of 32 snowballs, but instead got 4 stacks of 16 snowballs) and the error in the log.

/rotate command also seems to have this issue. If you run /rotate @s ~30 ~ while riding something, the horizontal rotation is interpolated.

I think this issue should be considered more important than before, especially since the main reason /rotate was added to the game was to rotate while riding.

Does not occur in 1.21.1. It seems it was fixed somewhere between 1.20.4 and 1.21.1

Also here are the commands for recent versions.

/give @s shield[custom_data={Cap:1b}]
/execute if predicate {condition:entity_properties,entity:this,predicate:{equipment:{mainhand:{predicates:{custom_data:{Cap:1b}}}}}}

Changed the command from 400 armor stands to 1000 item displays, to make the lag more visible.

Also attached a video of reproducing the bug.

MC-276312

Scores still get lost on zombie-drowned conversion. Still not fixed in 24w36a

This issue is different from MCPE-165278. I know that depth-first/breadth-first order can change the logic of a command, but that doesn't explain how the forked branches are changing their execution position even though there is no position-related subcommands. You can see that the commands in my report don't have `at @p`, which means that there is no means to re-capture the player's position.

Additionally, I would like to mention that this does not happen when running from a command block.

It seems that this bug has been fixed. I can't reproduce it in 1.20.5

Uh wait... I apologize, it appears that only the AttributeModifier tag is lost, not the entire item. I wrote them incorrectly at first.