Separate application commands with same name+type but in different guilds don't work

[shiftinv]

Summary

see title

Reproduction Steps

Create two commands with the same type (e.g. both slash) and same name, but with different guild_ids

Minimal Reproducible Code

@bot.slash_command(name="test", guild_ids=[id1])
async def test1(inter: disnake.GuildCommandInteraction):
    pass

@bot.slash_command(name="test", guild_ids=[id2])
async def test2(inter: disnake.GuildCommandInteraction):
    pass

Expected Results

One command gets registered in one guild, while the other one gets registered in the other guild

Actual Results

  ...
  File "...\disnake\test_bot\main.py", line 108, in <module>
    async def test2(inter: disnake.GuildCommandInteraction):
  File "...\disnake\ext\commands\interaction_bot_base.py", line 500, in decorator
    self.add_slash_command(result)
  File "...\disnake\ext\commands\interaction_bot_base.py", line 241, in add_slash_command
    raise CommandRegistrationError(slash_command.name)
disnake.ext.commands.errors.CommandRegistrationError: The command test is already an existing command or alias.

Intents

all

System Information

latest / 2025dfb

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.
• I have removed my token from display, if visible.

Additional Context

This is technically also an issue for prefix commands, although those don't really have a concept of guild-specific commands. The only thing that would emulate something like that is a @commands.check(lambda ctx: ctx.guild.id == ...).

The primary reason for all this is that the InteractionBotBase.all_slash_commands dict uses the command names as keys; fixing this would likely need a pretty large refactor, and I'm unsure how methods like InteractionBotBase.get_slash_command would work.

^{thanks for the hint, alento}

[EQUENOS]

Implementing this would definitely be an interesting experience!
I suspect that we can't do anything better than just indexing the commands of one type by (name, set_of_guild_ids). This will certainly damage the current structure of InteractionBotBase, however, it might be worth it. We'll have to make some breaking changes to .all_slash_commands (and other 2 attrs), maybe even replace them with something else. I don't know if it's a good idea though. Let me know if you have something to share on this topic.

[alentoghostflame]

Might as well comment here to bump it, and perhaps provide some guidance for anyone wanting to implement this. For context, I'm the main slash developer for Nextcord.

In NC, we store all application commands in a dictionary, with the keys being a tuple with three values, which I call a "signature": command name, command type (slash, message, user), and guild ID (None for global).
Any commands that share a signature will overwrite each other on Discord, and thus would "collide". Getting all slash commands specifically could be a property that iterates though the storage dictionary and returns all commands with the slash type.

I haven't worked with the inner workings of Disnake's application commands that much, so what I said might not be compatible at all if what you guys have setup, but just wanted to drop off what my solution to this was.

[Chitter777]

I ran into this problem too. But I tried to create slash command and user command.

[shiftinv]

I ran into this problem too. But I tried to create slash command and user command.

Creating application commands with the same name but different types was fixed in v2.4.0 (#254), if you're still seeing issues on the latest version feel free to open a new issue.