#Issue when using synchronise_interactions in multiple Guilds

1 messages · Page 1 of 1 (latest)

modern ether
#

I've never had this issue before besides when expanding my bot to more than one guild. I'm running into this issue.

 

for guild in guilds:
  ...
  for command in guild_cmds:
    ...
    self.bot.add_interaction(
      command=SlashCommand(
          name=command.name,
          description=command.description,
          options=options,
          scopes=[guild],
          callback=create_ctx_callback(endpoint=E,
                                       embed_data=embed_data_copy,
                                       dm=self.data_manager,
                                       get_roles=self.get_roles # function
                                       )
        )
    )  
  
  await self.bot.synchronise_interactions(delete_commands=True)

and I get the error:

warm zenithBOT
#

Hey! Once your issue is solved, press the button below to close this thread!

warm zenithBOT
modern ether
#

thats the entire error

#

the reason I don't put a scope either on synchronise_interactions is because it doesnt seem to be reliable with syncing commands.

rough veldt
#

huh, odd

#

for me scopes work just fine

#

i can look into it

modern ether
#

@rough veldt I still have not been able to solve this and its very pressing for issue for me. I have contributed to the library before and I'm wiling to do a deeper dive but overall I need you all's help to understand the more complex logic since you all have more experience with this library

#

essentially whats happening at a high level, is that when the app loads, it adds the commands in reference to this example snippet above, it starts with one scope (the main server). when a second server is added to list (whether dynamically while running or even after an entire app restart) that error occurs. it happens when a new commands are being synced:
await self.bot.synchronise_interactions(delete_commands=True)

rough veldt
#

hm wack

modern ether
#

it seems like this line:

local_cmd_json = next((c for c in local_cmds_json[cmd_scope] if c["name"] == str(local_cmd.name)))

specifically,


local_cmds_json[cmd_scope]

the cmd_scope never existed, so it would not be in this dict.

rough veldt
#

except the local command should exist

#

the remote shouldnt

#

that being said if youre just doing cmd.scopes.append after the bot starts i actually do expect this

modern ether
#

correct. the local command should be added by the add_interaction

modern ether
rough veldt
#

yeah, which is the interesting part

#

i feel like i need more of how you load in commands, it appears youre doing it dynamically even on reboot which may introduce things

modern ether
#

yes, I am dynamically loading in the commands from a backend/db

heres another snippet/example:


guild_defined_commands = self.factory.portal.get_commands_server_defined()

for example, guild_defined_commands will look like this:

[
    {
        "guild_id": "1126639321752031302",
        "max_requests": 400,
        "commands": [
            {
                "name": "command_name",
                "card": "card title",
                "description": "card desc",
                "resource": "%D/QM.png",
            }
    }
]

then:


for guild in guild_defined_commands:
  guild_id = guild['guild_id']

  for command_obj in guild['commands']:
    ...
    command = command.model_validate(command_obj) # pydantic obj
    self.bot.add_interaction(
      command=SlashCommand(
          name=command.name,
          description=command.description,
          options=options,
          scopes=[guild],
          callback=create_ctx_callback(endpoint=E,
                                       embed_data=embed_data_copy,
                                       dm=self.data_manager,
                                       get_roles=self.get_roles # function
                                       )
        )
    )  
  
  await self.bot.synchronise_interactions(delete_commands=True)

note the attempt to sync is outside the command loop but inside guild loop. i did this to avoid rate limits. there is code omitted here but somewhere between each loop is a slightly delay.

rough veldt
#

and does this process happen before the bot actually starts or after?
(before bot.start/astart or after/in an event)

modern ether
#

it happens after, on startup event

#

hm, so on startup it starts with nothing local. im assuming it localizes the remote commands?

rough veldt
#

probably, i was more asking so i can try to replicate this issue

modern ether
#

im also using astart()

rough veldt
#

right

rough veldt
#

my basic replication hasnt caused an error but im going to try the above to see if that causes something

#

yep, there we go

#

im going to mark this as not a lib issue, or at least not a high priority one

#

ipy very much expects you to have all scopes for the command ready when you do add_interaction

#

since youre using a new slash command with the same name per scope, things get... weird

#

at best this is undefined behavior

#

that being said, even if it is undefined, im not exactly sure why things get weird

modern ether
rough veldt
#

yes

#

technically this behavior should probably be okay but again, its technically undefined

#

im still investigating on my end regardless but thats worth noting i think

modern ether
#

ok - cool. in the case where I need to update live, would we not run into the same issue even when we reverse the logic?

rough veldt
#

i dont think so

#

okay i was wrong this is not an edge case this was just missed by everyone 😅

#

i'll be making a fix pr soon

modern ether
#

oh, haha. thanks for that. we've been delaying a release due to that so this is very much appreciated

rough veldt
modern ether
#

let me also test it

modern ether
#

thanks for the prompt fix. it does work. i saw the note about subcmds and fortunately i dont utilize any

rough veldt
#

for the best, really 😅

#

subcommands are a pain to manage backend wise because of how discord stored them

modern ether
#

just bumped the PR 🙂

modern ether
#

thank you @rough veldt!