Autocomplete shouldn't use cached results when another option has changed

[abitofevrything]

Description

Sometimes, the choices an application returns for an autocomplete interaction can depend on the values of other options that the user may or may not have filled in. This works fine most of the time, but when the results for an option are cached and the value of a different option changes, the cached result is still used for the original option even though the application might have responded differently when the other option changed.

Steps to Reproduce

1. Create a slash command with two options, option A with autocomplete enabled.
2. Set up the autocomplete handler in a way that the values returned for option A autocompletion depend on the value of option B (a simple setup to reproduce: have the choices be what the user has currently typed in B if they have typed anything, else return some constant value).
3. Fill in option B, then see what autocomplete value is suggested for A. It should be the value entered in B.
4. Cancel the previous command and instead let the autocomplete load for option A (producing the constant value), then fill in B. Switching back to option A, the suggested autocompletion is still the constant value and not the value we just entered in B.

Expected Behavior

The cached autocompletion results should be invalidated whenever any option changes, not just the option the completions are for.

Current Behavior

Cached autocompletion results are still used when another option changes.

Screenshots/Videos

Code used: https://gist.github.com/abitofevrything/7a1c633ca060d044e0fb3daa5b86ccd7

Client and System Information

• Stable 124823 (6ac2437)
• Host 0.0.17
• Linux 64-Bit (5.17.3-Artix1-1)

Library used in video: nyxx

[Elitesparkle]

Any update? I encountered this issue today and I'm wondering when it will be fixed.

[Vioshim]

Same here, it's been a bit of an issue with making the full transition to slash commands

[nerblock]

This is very problematic for our usecase. We needed to setup many slash commands instead of just one because of this behaviour. It would be nice to have caching based on the combination of all the options of a given command.

[Scrxtchy]

Having this issue too. I have some code that is fetching leaderboard data from a website, a user is able to use a non-required field to filter the result to a single player name, but as the leaderboard data has different requests per course we rely on data in a required field to provide autocomplete results to the user.

I believe it would be nice to provide the API with a list of required options for another option to be available to a user, and if any of these options have their value changed, delete the cache

[XCanG]

I had a similar case, which I originally described in library discussion, I would also like to have separate cache when multiple fields being used.

[ptlthg]

I also want this to be fixed (or made configurable). I have a lot of bot commands that use autocomplete for player names, with a secondary input to select that player's specific world/profile/leaderboard/etc which is currently not possible when used in combination with the name input. One player might have 3 different profiles with different names, and another player might only have 1 profile for example. One player might be in 20 different leaderboards and another player might only be in 3.

It can be worked around, it'd just be a much better experience for both developers and users to have this functionality built into the inputs.

[BlckViper]

I also have the same issue. Because of the issue i literally can't use multiple autocompletes which is pretty boring. Therefore i have to use other opertunities to programm something but which is not that good looking as it could be.

Please fix the bug where editing an existing autocomplete component before the last autocomplete component cause the slash command to crash.

[wolfieboy09]

Super annoying bug

[advaith1]

@BlckViper if you are encountering a crash, that is a separate issue, and you should open a new GitHub issue with reproduction steps.

[freya022]

Related discussion: https://github.com/discord/discord-api-docs/discussions/5121