CommandAPI version

11.2.0

Minecraft version

26.1

Are you shading the CommandAPI?

Yes

What I did

One particular problem caused by the underlying issue was brought up by 3add on Discord. They ran code that achieved something like this:

new CommandAPICommand("test")
	.withArguments(new TextArgument("test"))
	.executes(info -> {})
	.register();

CommandAPI.unregister("test");

new CommandAPICommand("test")
	.withArguments(new GreedyStringArgument("test"))
	.executes(info -> {})
	.register();

What actually happened

This code incorrectly triggered the command conflict logic:

[14:03:44 INFO] [dev.threeadd.veloskript.plugin.elements.command.ScriptCommand]: Unloading command test
[14:03:44 ERROR] [dev.jorel.commandapi.CommandAPIMain]: Failed to register command:

  test test<TextArgument>

Because it conflicts with this previously registered command:

  test test<GreedyStringArgument>

What should have happened

The command conflict logic is meant to detect structures that can be registered into Brigadier, but would cause problems once actually executed. Since the first version of the command was unregistered, it will not actually interfere with registering the second command. There are no real problems with registering the second command, so it should have been allowed.

Server logs and CommandAPI config

No response

Other

The command conflict logic is based on the CommandAPIHandler.registeredCommands list. However, we don't remove entries from this list when commands are unregistered.

CommandAPIHandler.registeredCommands is also used when generating usage text on Bukkit, so that is also likely affected by this. I.e., old branches that got unregistered might still appear in the usage text, which is part of what is happening with #685.