The bug
Expected command exceptions (com.mojang.brigadier.exceptions.CommandSyntaxException
) are written to the log file, for example when a selector cannot find an entity or when the syntax of a command is wrong. This can cause huge log files (for example 5 GB, see
) when commands are running every tick.
Especially with the command changes most of the previously used commands are now incorrect and cause syntax errors.
These expected exceptions should be normal command feedback and therefore nothing should be logged.
Note: Exceptions happening because a command malfunctions should probably be logged.
Affected situations
functionswas fixedCommands run in chat (including using written books)
/give @s minecraft:written_book{author:"a",title:"a",pages:["{\"\":\"click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/kill @e[type=item]\"}}"]}
Commands run by command blocks (including minecart command blocks)
/give @s minecraft:written_book{author:"a",title:"a",pages:["{\"\":\"click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/kill @e[type=item]\"}}"]}
Command run when clicking signs
/setblock ~ ~ ~ sign{Text1:"{\"text\":\"click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/kill @e[type=item]\"}}"}
Linked issues
Attachments
Comments


Thanks, it is worth noting that previously, commandblocks never outputted errors to the log files, regardless of any gamerules. But playerbased error messages are always in the log files regardless of gamerules.
It is definitely new that commandblocks output errors to the log. Most notably syntax errors from previously vaild commands.

I'm pretty sure that command-blocks would have logged errors – just only when the command handler behaves incorrectly (e.g. MC-101113), not when there is a syntax error from the user. The syntax error logging is new and problematic.

im fine with command blocks logging syntax errors, but that no entity was found isn't really a syntax error, so it shouldn't be logged
This is not just a problem with proper syntax errors from command blocks that haven't been updated. It's throwing syntax errors on updated commands for "Entity not found". I'm having my log file spammed with
[Server thread/ERROR]: Couldn't execute command for @: execute as 0-0-5750-0-1 run execute as @s[nbt={Age:50}] at @s run function wp_pregen:loop
com.mojang.brigadier.exceptions.CommandSyntaxException: No entity was found
Having a command block only run a function when a specific entity exists (or in this case, when the specific entity meets certain conditions) should really not come up as a syntax error, surely.
Would like to emphasize this is not just old commands as stated in the above comment. If a current command fails to for example find an entity with execute as/if/unless/at, it will spam the log and my live server log is now useless because i cannot see anything that is happening cause the text scrolls up so fast. disabling logAdminCommands and commandBlockOutput does not help.
Confirmed for 17w49b

Looks like it's still happening in 17w50a.

Looks like it's still happening in 17w50a.
At least for commands run in chat (including using written books), in command blocks (including minecart command blocks) and signs.
/give @s minecraft:written_book{author:"a",title:"a",pages:["{\"\":\"click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/kill @e[type=item]\"}}"]}
/setblock ~ ~ ~ sign{Text1:"{\"text\":\"click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/kill @e[type=item]\"}}"}
Fix Version/s:
Future Version - 1.13+
Please wait for the next snapshot.

I changed the report and hope it still reflects the problem you are describing good enough, if not, feel free to revert the changes.
I'm pretty sure that before, exceptions would still log an error message even if
logAdminCommands
was set to false. It's just that now, any type of exception, even normal parse exceptions, logs an error (see MC-121662). Will check.EDIT: Confirmed that that is the case via MC-101113 in 1.12.2, so logging when an error occurs regardless of the gamerule is WAI. However, this is still a problem. I'll link this issue as related to MC-121662.