Kicking the bot from its dev guild and inviting it again drops the slash commands

[gustaveWPM]

Which package is this bug report for?

discord.js

Issue description

1. Bring a bot to only one guild, which will be called here its "Dev guild".
2. Then, register slash commands using:

await rest.put(Routes.applicationGuildCommands(clientId, guildId), { body });

3. .login() your discord.js client.
4. Run a slash command on your Discord guild via the Discord GUI, it should work fine.
5. Kick the bot from its dev guild
6. Invite the bot again
7. Try to run a slash command again: your slashs commands are dropped and you have to restart your bot!

Code sample

No response

Versions

discord.js: 14.15.3

Issue priority

Low (slightly annoying)

Which partials do you have configured?

Not applicable

Which gateway intents are you subscribing to?

Not applicable

I have tested this issue on a development release

No response

[gustaveWPM]

Also, this is why I'm asking how I can programatically reinitialize the bot to handle this edge case without using process.exit().

• What are other ways to "Reboot" a Discord bot using Discord.js? #10320

[Jiralite]

This is expected behaviour.

---

Considering #10319 and this, it would be wiser for you to join the support server to receive help. Proficients in that server will escalate issues as needed.

[gustaveWPM]

This is expected behaviour.

Lmao, this is totally a bug, but fine.

[almostSouji]

There are two scopes you can deploy commands to: commands local to the guild and global commands:

1. Global commands are available to be used from any guild the bot is in. Accordingly, global commands will be available after re-invitation, after all they are globally available on just any guild.
2. Local commands are specific to the guild they are deployed to and removing an application from a server (for example through guild settings > interactions or kicking the associated bot user) will also "uninstall" the app from the server. This includes the removal of all deployed guild-specific commands. On re-invitation you have to deploy these commands again, if you have a use case for guild-specific commands.

Since you are using the Routes.applicationGuildCommands route, you are deploying local commands (2).
This is not a bug in discord.js but expected upstream behavior of the Discord API
You can read more about command scopes and contexts here: https://discord.com/developers/docs/interactions/application-commands#registering-a-command

[gustaveWPM]

There are two scopes you can deploy commands to: commands local to the guild and global commands:

1. Global commands are available to be used from any guild the bot is in. Accordingly, global commands will be available after re-invitation, after all they are globally available on just any guild.

2. Local commands are specific to the guild they are deployed to and removing an application from a server (for example through guild settings > interactions or kicking the associated bot user) will also "uninstall" the app from the server. This includes the removal of all deployed guild-specific commands. On re-invitation you have to deploy these commands again, if you have a use case for guild-specific commands.

Since you are using the Routes.applicationGuildCommands route, you are deploying local commands (2). This is not a bug in discord.js but expected upstream behavior of the Discord API You can read more about command scopes and contexts here: https://discord.com/developers/docs/interactions/application-commands#registering-a-command

First of all: thank you a lot for this very insightful answer.

I understand that it is desirable to "Eject" slash commands as soon as they become pointless.

However, I think that if they're "Ejected" automatically when they're no longer needed, then they should be "Plugged" again as soon as they're needed again.

Simply because the current behaviour is very confusing for a user.
Because this is a very insidious side-effect that's hard to reason about.

It's pretty tricky to understand exactly where it's coming from in the first place, once you're confronted with this implicit "Eject" of slash commands.

It can also be panic-inducing, because, next, you wonder what else you might have that would also be "Ejected" like this.
And so you need to "guess" how you have to plug it in again (and what you have to plug in again).

Restarting the bot from scratch (and even more: by killing the process) because a user doesn't understand at all how to resume it properly at runtime is an aggressive solution. I understand that killing the process if it came to a state which is impossible to understand for me is a "straightforward" solution. But honestly, it doesn't make me happy at all to kill a whole process and restart it just because it came to a rabbit hole which is really hard to understand from a user perspective.

I think there could be a simple solution to make these side effects a little more comfortable to work with.
Simply logging them would be a plus in my opinion.

The best would be to make them as invisible as possible, as "For free" as possible.
Both in "deallocating" and "reallocating".
But that could potentially lead to undecidable situations that I may not be aware of.

[almostSouji]

You seem to be conflating the two issues you opened in your message.
This one is about kicking the bot, which is expected upstream behavior. If you want to suggest a change to how Discord handles this, please open a feedback discussion in the upstream repository: https://github.com/discord/discord-api-docs/discussions