Unexpected Behavior in Single-Select Filter After Reset

Environment:
• Amazon QuickSight
• Dashboard with a single‐select dropdown filter on a “Route” field containing many values
• Default filter value set to “Route A”

Description:

We’re seeing inconsistent behavior in a single-select dropdown filter that requires searching through many items:
1. On dashboard load, the filter defaults to Route A and all visuals render correctly.
2. Searching for and selecting Route B updates the visuals as expected.
3. Clicking the filter’s menu (•••) and choosing Reset returns the filter to Route A.
4. After that reset, searching for and selecting Route B again does not reapply the filter—visuals remain unchanged.
5. Curiously, selecting a different value (e.g. Route C) does work normally, even after a reset.

Steps to Reproduce:
1. Create a single-select filter on a column “Router”, that has a lot of options, set the default to Route A.
2. Publish and open the dashboard; confirm visuals reflect Route A.
3. Use the search box in the dropdown to pick Route B; confirm visuals update.
4. Open the filter menu (•••) and hit Reset; confirm it returns to Route A.
5. Use the search box to pick Route B again; observe that visuals do not update.
6. (Optional) Pick Route C—it updates as expected.

Expected Behavior:
• Any selection in the single-select filter should trigger a refresh of all dependent visuals, regardless of whether the value was previously selected before a reset.

Actual Behavior:
• After using Reset, re-selecting the same filter value (e.g. Route B) is ignored by the dashboard; it only works again if you pick a different value first.

Additional Notes:
• This appears to be a state-management issue in QuickSight’s filter control—after a reset, the engine treats a re-selection of the same value as “no change,” even though the filter did revert to default.
• Selecting any brand-new value (one not previously chosen in the session) always works correctly.

Request:

Has anyone encountered this behavior? Is there a recommended pattern or setting to ensure that re-selecting the same value actually re-triggers the filter update? If this is a known bug, any advice on ETA for a fix would be greatly appreciated. Thanks!

1 Like

Hello @lmudrek Hope this message finds you well!!

This behaviour appears to be related to how the filter state is managed internally. When the filter is reset to its default value and then the same value is selected again, qs may not recognise this as a change, thus failing to trigger the visuals’ update. Some possible solutions include: using a different default value, if feasible, by setting the filter to a value that is less likely to be selected immediately after a reset, which may help to avoid the issue; adding a dummy value to the dataset that can be used as the default, ensuring that any real selection will always trigger a change; or implementing a custom action, if it is possible to add scripts or customised actions, to force the visuals’ update whenever a filter change is detected, regardless of whether the value is the same as before.

Please, tell me if it helps you.

Hi @lmudrek,
It’s been awhile since we last heard from you on this thread, did you have any additional questions regarding your initial post?

If we do not hear back within the next 3 business days, I’ll close out this topic.

Thank you!

Hi @lmudrek,
Since we have not heard back, I’ll go ahead and close out this topic. However, if you have any additional questions, feel free to create a new post in the community and link this discussion for relevant information if needed.

Thank you!

Hi, the solution we used was change the filter type to textbox, so the user write and press enter.