Bug description
When using native filters with cascading dependencies in Apache Superset, clearing all filters using the "Clear All Filters" button causes the required time range filter (e.g., "Last week") to be set to No filter.
Because this time filter is marked as non-optional (enableEmptyFilter: false), and other filters depend on it via cascadeParentIds, this results in a backend query error when rendering dependent filters:
Error: INVALID_CAST_ARGUMENT: Value cannot be cast to timestamp: None
Steps to reproduce
- Create a native time filter (type Time range) and mark it as required.
- Add default value, 'Last Week'
- Create dependent value filters from dataset that reference this time filter in 'Values are dependent on other filters'.
- Go to the dashboard view, ensure filters are working as expected.
- Click "Clear All Filters".
-
Observe that:
-
The time filter is cleared to No filter, even though it's marked as required.
- Downstream filters immediately error with an invalid cast exception.
- Expected behavior: the time filter should reset to its default value (defaultDataMask) instead of clearing entirely.
Screenshots/recordings
Superset version
4.0.2
Python version
Not applicable
Node version
I don't know
Browser
Not applicable
Additional context
No response
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
Hello @harelorinctera! I'm Dosu, a friendly bot here to help you with bugs, answer your questions, and assist you in becoming a contributor. I'm here while you wait for a human maintainer. How can I assist you today?
The issue you're experiencing with the "Clear All Filters" button setting a required time filter to 'No filter' seems to be related to how Superset handles default values and required filters. When the "Clear All Filters" button is used, Superset should ideally reset the filter to its default value instead of clearing it entirely, especially if the filter is marked as required.
The logic for handling default values in native filters involves checking configurations like defaultToFirstItem and enableEmptyFilter. If defaultToFirstItem is enabled, the default value is set to the first item automatically. If enableEmptyFilter is false, a default value must be set when the filter is required [1][2].
In your case, it seems that the required time filter is not reverting to its default value when "Clear All Filters" is triggered, which leads to the backend query error due to the absence of a valid timestamp. This behavior might be a bug in the current version of Superset (4.0.2) you are using.
To address this, you might want to ensure that the default value logic is correctly implemented in your filter configuration. If the issue persists, it may require a fix in the Superset codebase to ensure that required filters revert to their default values when cleared, rather than being set to 'No filter'.
To continue talking to Dosu, mention @dosu.
Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other
Comment From: harelorinctera
This issue needs to be changed to type BUG and assigned to someone for fixing
Comment From: rusackas
It's an issue, so it's already a bug report. Pinging @sadpandajoe to see if we've run into this before in our QA suite.
Comment From: rusackas
Not sure if/when this'll be prioritized (there's a lot to do!) so if it's blocking you, please feel free to investigate and open a PR/fix if you have the bandwidth!
Comment From: amaannawab923
@rusackas Tested this out but was unable to reproduce on latest superset of crashing native filters , however Expected behavior: the time filter should reset to its default value (defaultDataMask) instead of clearing entirely.
This wont be the correct expected behaviour , Default only means the value on initial render , it doesnt mean that on clearing it will get set to default value , it is throwing the error in red that its required ... thats all what Required does , it disables the apply button & Gives red border to the input saying that it is required
Comment From: amaannawab923
Expected behavior: the time filter should reset to its default value (defaultDataMask) instead of clearing entirely.
I checked the code & this is not the behaviour of Superset native filters , if we want this behaviour , this needs to be discussed & implemented cc: @rusackas
Comment From: harelorinctera
If a filter has dependent filters, it must have a default value set. On "Clear All Filters", it should reset to its default value instead of being cleared entirely — otherwise, it breaks downstream filters expecting a required value. @amaannawab923 @rusackas
Comment From: amaannawab923
i see , I think that case is not handled , Seems like an edge case of dependant filters , default value & clear all filters combined .... Will need to handle this @harelorinctera
Whats your opinion on this @rusackas
Comment From: harelorinctera
We are quite a big company using Apache Superset as a dashboard for one of our products and going into production with this product very soon, this issue is high priority to us - would love your help closing this up as soon as possible 🙏
Comment From: Vitor-Avila
Hey @harelorinctera,
I agree with @amaannawab923 here -- Clear All is meant to clear all filters. The idea is that you want to remove all values from all filters to be able to start a new selection "fresh". It seems you're actually looking for a "Reset" button that would restore the dashboard state to its default value, which is a bit different from the original intent with the Clear All button.
In my opinion, the expected behavior here would be that clicking on Clear All would clear all filters (including the required time range filter) and then filters that depend on this one should show all options (unfiltered selection).
The behavior I'm currently seeing in master is aligned with this:
https://github.com/user-attachments/assets/0a74e963-cefc-456f-b2ad-67f6231adb36
@rusackas IMHO this could be a suggestion to actually implement a "Reset" button that restores the dashboard default state (I'd say that this button could even auto-apply).