Whitelist command: Lag & inaccurate error message

[dement6d]

Profile link

.

Description of issue

1. As you can see in the video i attached below, it took me 4 attempts to whitelist the username "1000". Every time the command failed with the result "That player does not exist", even though on the 4th try it whitelisted the player. This probably means that the whitelist command failed to fetch the UUID of the username for some reason (API ratelimit possibly), but the error message isn't accurate.
2. Almost every time I run the command, you can see in my video example that the server freezes until the command finishes. This affects the whole server, I've had another player tell me they almost died due to the lag when I tried adding someone to the whitelist. This issue is present in both the add and remove arguments of the command, as shown in the video

Plugin and Datapack List

Bukkit Plugins:

• FreedomChat, GrimAC, InvSeePlusPlus, LuckPerms, OgPlace, ProtocolLib, SuperVanish, ViaBackwards, ViaRewind, ViaRewind-Legacy-Support, ViaVersion, WorldEdit, WorldGuard

There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
There are no more data packs available

None of the plugins modify the behavior of the whitelist command

Server config files

.

Paper version

This server is running Paper version 1.21.1-89-master@1ed64f8 (2024-09-21T19:32:37Z) (Implementing API version 1.21.1-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.1-52-e08e667 (MC: 1.21.1)

Other

whitelist_issue.mp4

[lynxplay]

A) the way the code is structured would make a more meaningful error message along the lines of "rated limited" incredibly difficult to near impossible for us to implement without just fully re-implementing the whitelist command and player lookup logic.

B) The command doing its work on the main thread is something that recently was also discussed on #11155.

I think that there was generally some long term concerns over toying with some of this stuff due to stuff potentially expecting mutation to occur during execution
Moving the execution of the whitelist command off the main thread may simply break existing things that expect the command to finish its work immediately. The avenue of potentially exposing off-thread capabilities for this on an API level, allowing plugins to easily create "async whitelist" commands is something doable, but at least for me, modifying the vanilla command behaviour in that way is non desirable.

Will keep issue open for some other peoples feedback, maybe my view here does not represent the teams, but I don't think there is anything (for either a or b) that we can/should implement.

[lynxplay]

After some more feedback, we ended up closing the related PR linked above.
See that PR for the reasons we do not believe vanilla commands editing important data like that should have behaviour changes as drastic as their completion.