How to reproduce the bug
- Create a Filter Name A
- Create a Filter Name B
- Tick the checkbox the Values are dependent on other filters in Filter B and select A in VALUES DEPENDENT ON
- Click on Save
- Select some value in filter A
- Data API call will be done for Filter B and the option will be updated.
- Select some value in Filter B. For Example, Selected Asia.
- Remove the Filter Value in Filter A and select some other option.
- Data API call will be done for Filter B and the option will be updated.
- In Option of Filter B previously selected will be present and it's not coming from the Result of Data(API Call).
Expected results
If The Previously selected value is not present in the result of the dependent filter API call it shouldn't be present in the option or in the selected state.
Actual results
The previously selected value if it's not present in the result of the dependent filter API call its showing in the option or its getting selected also.
Screenshots
https://jam.dev/c/2e22ee9e-d1b2-48ba-a063-11dfe2584c8a
https://jam.dev/c/54743133-2a1e-4d79-bfa4-30e0d8cdc95c
https://jam.dev/c/bad93252-6c4c-4ade-bd7b-53108b245692
https://jam.dev/c/2e343713-d305-4b3d-b504-8c5d48b75647
https://jam.dev/c/5f3fa04b-c25f-4ea9-9108-c1059a3f9caf
https://jam.dev/c/c963fc06-e234-422e-85f5-60a8b7592574
Environment
(please complete the following information):
- browser type and version:
- superset version:
master - python version:
python --version - node.js version:
16.15.0 - any feature flags active:
Checklist
Make sure to follow these steps before submitting your issue - thank you!
- [Yes] I have checked the superset logs for Python stack traces and included them here as text if there are any.
- [Yes] I have reproduced the issue with at least the latest released version of the superset.
- [Yes] I have checked the issue tracker for the same issue and I haven't found one similar.
Comment From: sfirke
I can validate this in Superset 2.1.0 and agree that it would be better if when the user selects a new value in filter A, the value in filter B is reset. I thought this issue had already been filed but I'm not seeing another bug report so thanks for submitting this one.
The closest thing I see is this https://github.com/apache/superset/issues/22979 which is not identical.
Comment From: lchavas
Having the same issue here in 2.1.0
I can add that : - if you have 'Select first filter value by default ' active on the filters and click on the 'CLEAR ALL' button while parent filter is loading, you'll get 'null' as a selected value in child filters - if you have 'Select first filter value by default ' active on the filters and then click on the 'CLEAR ALL' button while parent and child filters are set, it will reset the parent filter but not the children. another 'CLEAR ALL' will then clear the children.
It feels like any change in the parent should cascade in the child filter, and child filters should be loaded only when the parent filter has finished loading.
Comment From: shubham1811
Having the same issue here in 2.1.0
I can add that :
- if you have 'Select first filter value by default ' active on the filters and click on the 'CLEAR ALL' button while parent filter is loading, you'll get 'null' as a selected value in child filters
- if you have 'Select first filter value by default ' active on the filters and then click on the 'CLEAR ALL' button while parent and child filters are set, it will reset the parent filter but not the children. another 'CLEAR ALL' will then clear the children.
It feels like any change in the parent should cascade in the child filter, and child filters should be loaded only when the parent filter has finished loading.
Yes Correct child filters should be loaded only when the parent filter has finished loading.
Comment From: lchavas
Updated to 2.1.1 with high hopes, parent filter being adressed in the changelog. However the issue is unchanged, and we still have to clear the first null value manually and change the subfilters manually everytime the parent filter is changed.
Comment From: Lbostwick
Does anyone know if this is addressed in SuperSet's latest update to version 3.0?
Comment From: Ian2012
This is still happening in superset 3.0
Comment From: rusackas
I'm assuming this is still happening in 3.1/4.0, but we'd appreciate verification of that almost as much as a PR :)
Comment From: giacomochiarella
@rusackas I can confirm it is still happening in 4.0.0 also
Comment From: hk-the-analyst
Facing the same issue in 3.1.1
Comment From: cmartinezdnn
I can confirm it is not fixed in 4.0.2
Comment From: cmartinezdnn
This issue is very annoying. Does anybody know how to fix it?
Comment From: hk-the-analyst
Still facing this issue in 4.1.1
Comment From: rusackas
Sorry to see this hasn't been prioritized... perhaps since it's a bit of an edge case. Investigation/PRs welcome.
Perhaps @dosu can shed some light on this.
Comment From: dosubot[bot]
This dependent filter issue is well-documented and still present in recent Superset versions. The core problem is that when a parent filter changes, the dependent filter's selected value isn't cleared if it no longer exists in the updated options. The frontend logic for native filters uses cascadeParentIds and merges parent filter state, but it doesn't automatically clear invalid selections in the child filter when the parent's options change. This can result in stale or invalid filter states, especially with async data loading or when using "Select first filter value by default"—leading to "null" or mismatched values in child filters.
There are no merged PRs or official fixes for this yet, but the relevant logic lives in the frontend, especially in the useFilterDependencies hook and the FilterValue and PluginFilterSelect components. The system is designed to recalculate options, but it doesn't enforce clearing the selection if the value is no longer valid. Some related logic for clearing invalid choices exists in the Explore view (handleMissingChoice), but not in the dashboard/native filter system.
A robust fix would likely involve updating the dependent filter's state to clear or reset its value whenever its options change and the current selection is no longer valid. This would need to be handled in the filter state management and/or the FilterValue component, possibly by comparing the current selection to the new options after each parent filter update. For now, there are no documented workarounds other than manually clearing the child filter after changing the parent.
For more technical details, see the relevant code and discussions: - Filter dependencies and state management - FilterValue component logic - Related issue on filter clearing and required filters
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
