discord/discord-api-docs

Read-repair behaviour for outdated commands no longer works

Opened this issue · 6 comments

Description

Previously, if you used a command that your client had cached shortly after that command was updated, the client would error once, then fix the local cache for your next use. This behaviour no longer works and requires a client restart every time.

Steps to Reproduce

  • Have your client cache a command
  • Update that command
  • Try to use the now-outdated cached version twice

Expected Behavior

Read-repair functionality should kick in and sync the local cache with the updated version of the command

Current Behavior

It keeps erroring without updating the cache, requiring a client restart every time

Screenshots/Videos

No response

Client and System Information

Unlikely to be version-specific as this has been occurring for months on many different versions

I can't reproduce this error
After the first use of the command it updates for me

Hmm I can't seem to reproduce this either on desktop or web using global commands. The new command payload is fetched and the next run works successfully.

@AlmostSuspense if this is still an issue - I have some Qs to help narrow this down:

  • what platform is this not working for?
  • are these global commands or guild commands?
  • if hitting the API directly, please let me know which endpoints you're using to create/update the command (PUT vs PATCH/POST), and provide example payloads for command create/update that repro this problem

Hi @Auralytical, this happens both on desktop and iOS (and maybe android too but i don't have one to test), I've only tested with global commands. I'm using a library, but it internally uses the PUT overwrite endpoint. The error looks like this now:

unknown integration error

For context, I used the "operator" command right after sending the PUT request which changed the name to "aaaaa", but this happens with any update, so all payloads

@AlmostSuspense While I wasn't able to reproduce this for other kinds of changes, I did by using PUT to change command names but not including the original command ids in the payload.

When command ids aren't included, we determine what commands needs to be created/updated/deleted based solely on the name. Changing the name this way causes the original command to be deleted and a new one created with a different id. This results in an "Unknown Integration" error on the client (rather than the usual "This command is outdated") because the cached command id is no longer valid and we weren't handling that case.

Not to say this is the exact bug you were running into, but I pushed a fix to beta and canary on desktop/web that will invalidate the client's command cache when an Unknown Integration error is received. Hopefully this will fix this issue for your other usecases too?

hi again @Auralytical not sure if the fix hasn't reached my client yet but I still experience the Unknown Integration error being stuck after the name was changed on web canary 457223 (c9d3312)

I have my commands stored as an API-ready json file which I use when the commands need to be updated on discord, so it's not really feasible to include the ids there for me

Okay nevermind, it seems even when only the description is changed (name remains the same), this error is shown no matter how many times I reuse the command

Image