Additional info

This section contains explanations of some library mechanics which may be useful to know.

App command sync

If you’re using disnake.ext.commands – Bot commands framework for application commands (slash commands, context menus) you should understand how your commands show up in Discord. By default, the library registers / updates all commands automatically. Based on the application commands defined in your code, the library automatically determines which commands should be registered, edited or deleted, but there are some edge cases you should keep in mind.

Unknown Commands

Unlike global commands, per-guild application commands are synced in a lazy fashion. This is due to Discord ratelimits, as checking all guilds for application commands is infeasible beyond only a handful of guilds. This can lead to situations where a command no longer exists in the code but still exists in the Discord API.

When an interaction for a previously removed guild command is received, a SyncWarning will be emitted. To rectify this, consider using await bot.bulk_overwrite_guild_commands(<guild_id>, []).

This will also occur when IDs are removed from the test_guilds kwarg of Bot or from the guild_ids kwarg of slash_command(), user_command(), or message_command().

Command Sync with Multiple Clusters

If your bot requires shard distribution across several clusters, you should disable command sync on all clusters except one. This will prevent conflicts and race conditions. The Discord API doesn’t provide users with events related to application command updates, so it’s impossible to keep the cache of multiple machines synced. Having only 1 cluster with CommandSyncFlags.sync_commands set to True is enough because global registration of application commands doesn’t depend on sharding.