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 (
PUTvsPATCH/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:
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
