Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
3 tasks done
shiftinv opened this issue Jan 8, 2022 · 4 comments · May be fixed by #1107
Open
3 tasks done

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

shiftinv opened this issue Jan 8, 2022 · 4 comments · May be fixed by #1107
Assignees
@onerandomusername
Labels
bug Something isn't working s: in progress Issue/PR is being worked on

Comments

@shiftinv
Copy link
Member

shiftinv commented Jan 8, 2022 •
edited
Loading

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
@shiftinv shiftinv added the bug Something isn't working label Jan 8, 2022
@EQUENOS
Copy link
Member

EQUENOS commented Jan 10, 2022

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
Copy link

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.

@onerandomusername onerandomusername moved this to Todo in disnake Apr 19, 2022
@onerandomusername onerandomusername added this to the disnake v2.6 milestone Apr 19, 2022
@Chitter777
Copy link

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

@shiftinv
Copy link
Member Author

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.

@onerandomusername onerandomusername self-assigned this Jul 27, 2022
@onerandomusername onerandomusername added the s: in progress Issue/PR is being worked on label Jul 27, 2022
@onerandomusername onerandomusername mentioned this issue Jul 27, 2022
Closed
8 tasks
@shiftinv shiftinv removed this from the disnake v2.8 milestone Feb 5, 2023
@EQUENOS EQUENOS linked a pull request Sep 18, 2023 that will close this issue
Open
8 tasks
@EQUENOS EQUENOS linked a pull request Sep 18, 2023 that will close this issue
refactor: store invokable application commands properly #1107
Open
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@onerandomusername onerandomusername

Labels
bug Something isn't working s: in progress Issue/PR is being worked on
Projects
disnake
Status: Todo
Milestone
No milestone
5 participants
@shiftinv @alentoghostflame @Chitter777 @EQUENOS @onerandomusername