Bug description
If we use filters between auto-refresh, switching tabs does not include the changed filters. What's more, filters show change, but the tab does not, making it look like legit information when it is not (for example, the changed year does not change the year for other tabs, making data look like for another year than it is).
It is crucial that all tabs in question are already loaded (not the first activation).
it is basic functionality of Superset, not some sort of hard-to-stumble-upon edge case.
If anyone will create reports with multiple tabs, and will read out through all of these then change filters, it is bound to happen sooner or later that if auto-refresh is enabled, then it will kick in before one will read all tabs again with a new filter solution.
To reproduce:
Create a dataset with two values, like year 2024/2025 Create a chart that just shows the value from this dataset Create a copy of the new chart Create a dashboard with 2 tabs and add the above charts to it, one for each tab Add a filter to the dashboard that filters this new dataset, making it single-choice, first default, and ordered by value.
Open dashboard Wait for tab A to load Move to tab B and wait for it to load Turn on auto-refresh with a tick of 30 seconds Wait for auto-refresh After info about auto-refresh fades, change the value in the filter bar Wait for another auto-refresh Move tab to A ERROR: Filter shows changed value (same as for tab B) for the chart, but it shows data for the filtering scenario that this tab was loaded initially with
Seeing is believing, so here is an example:
https://github.com/user-attachments/assets/ba39f416-6251-4d25-aca0-4cb8c9401185
Screenshots/recordings
No response
Superset version
4.0.2
Python version
3.9
Node version
16
Browser
Chrome
Additional context
No response
Checklist
- [ ] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [ ] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] 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: msyavuz
I can't reproduce this in 5.0, my guess is that this is either a state desync or some kind of race condition
Comment From: rusackas
Yeah, I feel like we've been tackling this sort of thing forever. I/we will try throwing Claude at this thing to see if we can get some tests/suggestions/solutions going here.