Unhandled CommandSyntaxException from DidYouMeanListener when using /oneblock border color green

[mrfloris]

Expected behavior

Description

Running the documented Border color command:

/oneblock border color green

causes an unhandled exception in BentoBox's DidYouMeanListener.

The exception occurs approximately five seconds after the original command. The stack trace indicates that DidYouMeanListener.acceptPending() attempts to dispatch a shortened command through Player#performCommand().

The final Brigadier error points to the end of:

oneblock border

rather than the complete command originally entered.

The current Border documentation lists the expected syntax as:

/[player command] border color {red|green|blue}

Documentation:
https://docs.bentobox.world/en/latest/addons/Border/

Expected behavior

One of the following should happen cleanly:

• The player's border color is changed to green.
• A permission or usage message is shown if the player cannot use the command.
• An invalid command is rejected without producing a server exception.

No exception should escape from a scheduled BentoBox task.

Actual behavior

BentoBox generates an unhandled CommandException from DidYouMeanListener.lambda$acceptPending$1.

Observed/Actual behavior

[16:57:07 INFO]: albertrut455 issued server command: /oneblock border color green
[16:57:12 WARN]: [BentoBox] Task #43963787 for BentoBox v3.21.1-SNAPSHOT-b304 generated an exception
org.bukkit.command.CommandException: Unhandled exception executing 'oneblock border color green' in org.bukkit.craftbukkit.command.VanillaCommandWrapper(oneblock)
        at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:945) ~[paper-26.2.jar:26.2-71-5563e58]
        at org.bukkit.craftbukkit.entity.CraftPlayer.performCommand(CraftPlayer.java:764) ~[paper-26.2.jar:26.2-71-5563e58]
        at BentoBox-3.21.1-SNAPSHOT.jar//world.bentobox.bentobox.suggestions.DidYouMeanListener.lambda$acceptPending$1(DidYouMeanListener.java:83) ~[?:?]
        at org.bukkit.craftbukkit.scheduler.CraftTask.run(CraftTask.java:78) ~[paper-26.2.jar:26.2-71-5563e58]
        at org.bukkit.craftbukkit.scheduler.CraftScheduler.mainThreadHeartbeat(CraftScheduler.java:474) ~[paper-26.2.jar:26.2-71-5563e58]
        at net.minecraft.server.MinecraftServer.tickChildren(MinecraftServer.java:1768) ~[paper-26.2.jar:26.2-71-5563e58]
        at net.minecraft.server.MinecraftServer.tickServer(MinecraftServer.java:1621) ~[paper-26.2.jar:26.2-71-5563e58]
        at net.minecraft.server.dedicated.DedicatedServer.tickServer(DedicatedServer.java:404) ~[paper-26.2.jar:26.2-71-5563e58]
        at net.minecraft.server.MinecraftServer.processPacketsAndTick(MinecraftServer.java:1679) ~[paper-26.2.jar:26.2-71-5563e58]
        at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1349) ~[paper-26.2.jar:26.2-71-5563e58]
        at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:303) ~[paper-26.2.jar:26.2-71-5563e58]
        at java.base/java.lang.Thread.run(Thread.java:1516) ~[?:?]
Caused by: com.mojang.brigadier.exceptions.CommandSyntaxException: Incorrect argument for command at position 16: ...ck border <--[HERE]

Steps/models to reproduce

1. Run BentoBox with AOneBlock and the Border addon enabled.

2. Join as a player in the AOneBlock game mode.

3. Execute:

   /oneblock border color green
   

4. If a “Did you mean?” prompt appears, accept the suggested command.

5. Observe the scheduled BentoBox task exception in the console.

BentoBox version

Server: Paper 26.2
Paper build: 26.2-71-5563e58
BentoBox: 3.21.1-SNAPSHOT-b304
Database: JSON

Loaded game worlds:
acid (acid): Overworld
cave (cave): Overworld
oneblock (oneblock): Overworld
skyblock (skyblock): Overworld
skygrid (skygrid): Overworld

Loaded addons:
AcidIsland 2.1.0-SNAPSHOT-b1123
AOneBlock 1.26.2
Biomes 2.3.2-SNAPSHOT-b349
Border 4.8.4-SNAPSHOT-b319
BSkyBlock 1.20.0-SNAPSHOT-b838
CaveBlock 1.23.2-SNAPSHOT-b520
Challenges 1.8.0
FarmersDance 1.2.2-SNAPSHOT
Greenhouses 1.10.0
Level 2.28.0-SNAPSHOT-b751
Limits 1.29.1
MagicCobblestoneGenerator 2.10.0
SkyGrid 2.2.3
TopBlock 2.0.0-SNAPSHOT-b70
Warps 1.19.0-SNAPSHOT-b433

Plugin list

n/a

Other

This may involve two related problems:

1. The documented Border color command is not being recognized in the AOneBlock command tree, possibly because of command registration or permission filtering.
2. DidYouMeanListener.acceptPending() dispatches the pending suggestion through Player#performCommand() without safely handling the resulting CommandException/Brigadier exception.

The position shown in the Brigadier exception suggests that the accepted pending command may be oneblock border, even though the player originally entered oneblock border color green.

[tastybento]

Thanks for the very detailed report — the stack trace and the cursor position in the Brigadier error were enough to pin this down exactly. You were right that it is a BentoBox issue, and both of the problems you suspected are real.

/[gamemode] border color green is a valid Border command. IslandBorderCommand registers type and color as sub-commands, so the documentation is correct. What broke it is the Brigadier command registration added in BentoBox 3.21.1 (two days before your report).

BentoBox puts a permission check in each sub-command literal's Brigadier requires predicate so clients only see commands they can use. Hiding a node that way is not passive:

• CommandNode#getRelevantNodes returns only the literal matching the typed token, so the catch-all argument beside it is never considered;
• CommandDispatcher#parseNodes then silently skips that literal when canUse(source) is false.

Your player did not have aoneblock.border.color, so the parse walked oneblock → border, dead-ended at color, and threw INCORRECT_ARGUMENT at cursor 16 — which is precisely where color starts in oneblock border color green, matching the ...ck border <--[HERE] in your log. The command line never reached BentoBox, so instead of "you do not have permission" you got a raw Brigadier error and nothing ran.

The rest follows from Paper reporting any CommandSyntaxException from Commands#finishParsing as an UnknownCommandEvent, not just genuinely unknown commands:

1. BentoBox's did-you-mean matcher re-attaches tokens it could not match verbatim, so it suggested the very line that had just failed — which is why the accepted command looked identical to what was typed;
2. accepting it re-dispatched through Player#performCommand in a scheduled task with nothing catching what Bukkit throws — your unhandled CommandException.

Fixes

• Run our own commands that Brigadier will not parse BentoBox#3042 — a command line of ours that Brigadier refuses to parse is now dispatched through the command tree, which checks its own permissions and reports for itself (so you get the permission message, not a syntax error); the matcher never suggests a line identical to what was typed; and the deferred dispatch no longer lets exceptions escape the scheduled task.
• Declare the border colour and bordertype permissions #180 — addon.yml never declared [gamemode].border.color or the per-colour permissions, so they defaulted to op only, which is why the command was unusable for that player in the first place. Also fixes [gamemode].bordertype, which was declared but never checked (the command asks for [gamemode].border.bordertype).

Workaround until the BentoBox fix ships: set general.brigadier-commands: false in BentoBox's config.yml, which goes back to the legacy command map registration. Or grant the player [gamemode].border.color.

🤖 Generated with Claude Code

[mrfloris]

Paper and Spigot have a method i believe that properly registers commands and allows for sub commands to be permission node locked as well I think. So

Your player did not have aoneblock.border.color

Would mean there shoudlnt' be a tab complete if they dont have the appropriate permissions.

So maybe rather than following a bbox structure for dealing with permissions and tab suggestions, i think it should use a modern method from paper api that would allow for this to be following industry standard.

But, i am not 100% sure.

Either way, i understand the error better, and i see there's a fix for now that handled this.