BUG: Dashboard filters "stick" to second part of Mixed Chart

[sfirke]

My mixed chart (with stacked bars and a five year rolling total line) on a dashboard starts off correct, but after some filtering on the dashboard, the filter conditions persist only with the rolling total line (Query B).

Here's the current state of the dashboard - see no filters applied and I've removed the filter related to bicycles:

Note that the Five Year Rolling Average line is way at the bottom, that's the problem due to the incorrectly-persisted filtering.

Then I click View Query and can see that the correct filtering is applied to the stacked bars (Query A) but a lot of previous filtering is also applying to the rolling line, Query B:

Query A SQL

SELECT TOP 10000 DATEADD(YEAR, DATEDIFF(YEAR, 0, [CrashDate]), 0) AS [CrashDate],
           [GretInjSev] AS [GretInjSev],
           COUNT(*) AS count
FROM dbo.[RoadsoftCrashes]
WHERE [GretInjSev] IN (1,
                       2,
                       3,
                       4,
                       5)
  AND [NFC] IN (N'3',
                 N' 4',
                  N' 5',
                   N'6',
                    N'7')
GROUP BY DATEADD(YEAR, DATEDIFF(YEAR, 0, [CrashDate]), 0),
         [GretInjSev]
ORDER BY count DESC;

Query B SQL - Lots of extra filtering incl. a repeated filter and the bicycle filter which I've since deleted:

SELECT TOP 10000 DATEADD(YEAR, DATEDIFF(YEAR, 0, [CrashDate]), 0) AS [CrashDate],
           COUNT(*) AS count
FROM dbo.[RoadsoftCrashes]
WHERE [GretInjSev] IN (1,
                       2,
                       3,
                       4,
                       5)
  AND [NFC] IN (N'3',
                 N'4',
                  N'5',
                   N'6',
                    N'7')
  AND [GretInjSev] IN (1,
                       2,
                       3,
                       4,
                       5)
  AND [GretInjSev] IN (1,
                       2,
                       3,
                       4,
                       5)
  AND [Bicycle] IN (1)
  AND [GretInjSev] IN (1,
                       2,
                       3,
                       4,
                       5)
GROUP BY DATEADD(YEAR, DATEDIFF(YEAR, 0, [CrashDate]), 0)
ORDER BY count DESC;

That's confirmed when I click Edit Chart and see two different sets of filters applied:

vs.

Environment

(please complete the following information):

• Firefox
• superset version: 2.0.0
• any feature flags active: ALERT_REPORTS, ENABLE_SCHEDULED_EMAIL_REPORTS, DASHBOARD_RBAC, GENERIC_CHART_AXES, EMAIL_NOTIFICATIONS

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if there are any.
• I have reproduced the issue with at least the latest released version of superset.
• I have checked the issue tracker for the same issue and I haven't found one similar.

[sfirke]

I was able to reproduce this with the example data set flights. Here's the dashboard with the filters in errored state:

When I click View Query I see the persisted filters on Query B did not release when I un-checked them:
Query A

SELECT "DAY" AS "DAY",
       "STATE" AS "STATE",
       COUNT(*) AS count
FROM public.flights
WHERE "STATE" IN ('CA',
                  'IL',
                  'NY')
GROUP BY "DAY",
         "STATE"
ORDER BY count DESC
LIMIT 10000;

Query B

SELECT "DAY" AS "DAY",
       COUNT(*) AS count
FROM public.flights
WHERE "STATE" IN ('CA',
                  'IL',
                  'NY')
  AND "AIRLINE" IN ('EV')
  AND "COUNTRY_DEST" IN ('USA')
GROUP BY "DAY"
ORDER BY count DESC
LIMIT 10000;

[sfirke]

Seems like it could be related to #20952

[baguskna]

Hi, is there any follow up for this? We have replicated the same issue in our project. Look forward to find the fix

[rusackas]

I think #21114 plays a big role here, can you see if that improves the situation? CC @kgabryje

[kgabryje]

It should have been fixed by #21450 (CC @villebro). Closing, but we can reopen if problem persists

[sfirke]

Yep #21450 looks promising as a fix, thank you! Any chance this could make it into the 2.0.1 release? I just added a comment on that discussion thread requesting it. EDIT I see it is being included there, FYI to others.