discord-api-docs Autocomplete shouldn't use cached results when another option has changed

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

Create a slash command with two options, option A with autocomplete enabled.
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).
Fill in option B, then see what autocomplete value is suggested for A. It should be the value entered in B.
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

ezgif com-gif-maker

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

Apr 20 '22 21:04 abitofevrything

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

Nov 18 '22 14:11 Elitesparkle

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

Feb 01 '23 12:02 Vioshim

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.

Mar 29 '23 20:03 nerblock

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

Apr 06 '23 19:04 Scrxtchy

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.

Jul 06 '24 00:07 XCanG

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.

Aug 28 '24 00:08 ptlthg

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.