rusackas opened a new issue, #43024:
URL: https://github.com/apache/superset/issues/43024
### Bug description
`/api/v1/chart/warm_up_cache` fails to warm cache for dashboards using
native filters (the standard filter mechanism today). Warming produces a
different cache key than the one the browser actually requests, so the warmed
entry is never hit.
Originally raised as a discussion (#42382) with a solid root-cause analysis;
filing as an issue since it's a confirmed bug, not a question. I independently
verified both root causes against current `master` (verified myself by reading
the code, not just trusting the original report):
**1. Native filter defaults are silently dropped.**
`get_dashboard_extra_filters()` in `superset/views/utils.py` only reads the
legacy Filter Box `default_filters`/`filter_scopes` metadata:
```python
default_filters = json.loads(json_metadata.get("default_filters", "null"))
if not default_filters:
return []
```
It never looks at `native_filter_configuration` at all, so for any dashboard
built with native filters (not the deprecated Filter Box), this returns `[]` —
cache warming applies none of the dashboard's actual default filters.
Notably, a correct native-filter extractor already exists and is wired into
the real `/api/v1/chart/data` endpoint:
`superset.charts.data.dashboard_filter_context.get_dashboard_filter_context()`
/ `apply_dashboard_filter_context()` (see `superset/charts/data/api.py`).
`ChartWarmUpCacheCommand` just isn't using it — this looks like the right
mechanism for a fix to reuse rather than reinvent.
**2. Filter order affects the cache key.** `QueryObject.cache_key()` hashes
via `hash_from_dict()`, which calls `json.dumps(obj, sort_keys=True, ...)`.
`sort_keys` only sorts dict keys, not list element order — so the `filter`
list's order is significant to the hash.
`ChartWarmUpCacheCommand._warm_up_non_legacy_cache` appends dashboard filters
to the end of `query.filter` via `.extend()`; if the runtime path builds the
equivalent list in a different order, the cache keys won't match even when the
filter values are identical.
### How to reproduce
1. Create a dashboard with a native filter that has a static default value.
2. Add a chart to the dashboard, in scope for that filter.
3. Call `/api/v1/chart/warm_up_cache` with that chart/dashboard.
4. Open the dashboard in a browser and check whether the chart's request is
a cache hit — it won't be, because the warmed entry never included the native
filter's default.
### Superset version
6.x (master)
### Related
- #42382 (original discussion, root-cause analysis)
- #34837 (cache warm-up logic; also notes RLS makes user-scoped cache keys a
separate, harder problem)
- #29307
### Checklist
- [x] I have searched the GitHub issue tracker and didn't find a duplicate
bug report.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
