[commands v2] [perms v2] updating commands with the bulk upsert endpoints may cause the newly updated commands to not be visible to users
onerandomusername opened this issue · 25 comments
Description
Updating or creating commands using the bulk upsert endpoints may have the commands enter a state where the backend does not return the commands to a user when they attempt to use them
Steps to Reproduce
-
have admin or be owner
-
Create or modify a command with the global or guild bulk endpoint.
- There is no repeatable reproduction steps or payload, but creating a few different commands should result in a solution. See this comment below for something that may work.
-
establish this not a local caching issue and is instead an api issue by refreshing your client
Expected Behavior
The command is able to be used.
Current Behavior
The command is not provided by the api and cannot be used.
Screenshots/Videos
Client and System Information
library: disnake 2.5.0a
client: Canary 126462 (1f5f36e)
Current Workaround
If you a developer or moderator experiencing this issue, the current workaround is going into server settings and creating a permission override for each affected command, saving said changes, and then deleting the override if desired.
I got the same problem
Got the same issue which i posted in #4859 that i closed. reference for whoever needs that
The bug only effects the Desktop version, on the phone it does still work
I can still repro on Canary 126462 (1f5f36e) and Android 126.5
I've managed to test this on commands v1, of which this bug is not creatable. This is both a commands v2 and perms v2 bug, and I have updated the issue name accordingly.
I can still repro on Canary 126462 (1f5f36e) and Android 126.5
Stable 112009 works
Stable 112009 works
If by works, you mean this bug is not present, that's probably still a commands v1 (also known as backend v1) guild.
I am also having this issue on Stable 126462.
Stable 112009 works
If by works, you mean this bug is not present, that's probably still a commands v1 (also known as backend v1) guild.
App: 122.0 (31608) stable (Ipad)
Is also broken but only 1 command is missing
Same issue on Client and Web for me
Client: Stable 126462 (1f5f36e)
Web: Stable 126462 (1f5f36e)
Experiencing the issue only on desktop: Stable 126462 (1f5f36e). No issues on mobile (iPhone). The library used doesn't seem to play a role.
Experienced this issue constantly for local guild commands, seemed to work fine with global commands the one time I tried those.
I can reproduce this without permissions v2:
[ {
"name" : "hello",
"options" : [ {
"name" : "channel",
"description" : "No description",
"type" : 7,
"required" : true
} ],
"description" : "No description",
"type" : 1
} ]
It also just deleted the commands of another bot from the suggestions, making it unusable. I'm not sure how doing a PUT request for one bot, would affect the commands of an unrelated bot.
The command looks like this according to the API:
[ {
"name_localizations" : null,
"default_permission" : true,
"name" : "hello",
"guild_id" : "163772719836430337",
"options" : [ {
"name_localizations" : null,
"name" : "channel",
"description" : "No description",
"description_localizations" : null,
"type" : 7,
"required" : true
} ],
"description" : "No description",
"description_localizations" : null,
"id" : "971154443682848868",
"default_member_permissions" : null,
"type" : 1,
"application_id" : "420321485757087746",
"version" : "971154443682848869"
} ]And this is what the client receives from the backend:
Can confirm that - using the latest DiscordJS REST extensions, it essentially does NOT update permissions for guilds reliably when using PU. Most of the time, nothing happens when using default_member_permissions with my commands, they just remain inaccessible for all users, admins included.
That's a major problem, considering the whole premise of our bot is easily configurable permissions for guild-specific command/permission combos via setup commands available to admins.
Currently, command permissions v2 is a mess that was launched with little documentation for developers, leaving us mostly stranded and telling all the people requesting help to "just set up your permissions manually".
I literally don't understand what permission synching even means, considering bots cannot set command permissions any more via DiscordJS's normal OAuth flow.
It also just deleted the commands of another bot from the suggestions, making it unusable. I'm not sure how doing a PUT request for one bot, would affect the commands of an unrelated bot.
I've now witnessed this happen as well. An application had its commands updated, which disabled some commands on other bots, even for admins, until they had the same permission toggle workaround used on them.
When could we expect a fix or more info on the developers about it?
A fix has been deployed, but prior updates may still result in a corrupt state. We hope to have existing states updated by the end of today
This should be fully fixed now
This should be fully fixed now
Meaning, reload the bot and wait for the slash commands to work? So bot new invite?
@typpo ?
@typpo ?
It was a client issue I believe, just restart your client and it should be fixed.
Any word on this other issue? The value of default_member_permissions doesn't have any visual effect in the discord client #4863
With permissions v2 I think it's upto the Staff to set perms not the bot owner, I'm not sure..
It was a client issue I believe, just restart your client and it should be fixed.
@Athenua I have, however always comes only "The application did not respond" and then the slash commands are gone again. Then I have to reload Bot and so on. Already the normal Discord client?
Description
Updating or creating commands using the bulk upsert endpoints may have the commands enter a state where the backend does not return the commands to a user when they attempt to use them
Steps to Reproduce
have admin or be owner
Create or modify a command with the global or guild bulk endpoint.
- There is no repeatable reproduction steps or payload, but creating a few different commands should result in a solution. See this comment below for something that may work.
establish this not a local caching issue and is instead an api issue by refreshing your client
Expected Behavior
The command is able to be used.
Current Behavior
The command is not provided by the api and cannot be used.
Screenshots/Videos
Client and System Information
library: disnake 2.5.0a
client: Canary 126462 (1f5f36e)
Current Workaround
If you a developer or moderator experiencing this issue, the current workaround is going into server settings and creating a permission override for each affected command, saving said changes, and then deleting the override if desired.