fix(cachekey): use data_cache for chart query result invalidation#40493
Conversation
Code Review Agent Run #4ae5e8Actionable Suggestions - 0Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #40493 +/- ##
=======================================
Coverage 64.17% 64.17%
=======================================
Files 2592 2592
Lines 139299 139299
Branches 32347 32347
=======================================
Hits 89395 89395
Misses 48367 48367
Partials 1537 1537
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
SUMMARY
Fixes #40489.
POST /api/v1/cachekey/invalidatewas callingcache_manager.cache.delete_many(...)(which usesCACHE_CONFIG.CACHE_KEY_PREFIX), but the chart query results tracked byCacheKeyrows are written viacache_manager.data_cache(DATA_CACHE_CONFIG.CACHE_KEY_PREFIX).When a deployment configures the two caches with different prefixes (the recommended multi-cache setup),
delete_manyissuesDELagainst the wrong Redis prefix and silently misses every key. The metadata rows are cleared, but Redis keeps serving stale chart data until TTL expiry. The mismatch is invisible in default-config deployments because both prefixes resolve to the same value.Fix
One-line backend change in
superset/cachekeys/api.py:TESTING INSTRUCTIONS
cache_manager.data_cache(they previously exercised the buggy path;cacheanddata_cacheresolve to the same backend in the default test config so the asserts passed anyway).test_invalidate_uses_data_cache_not_default_cachepatches bothcache_manager.data_cache.delete_manyandcache_manager.cache.delete_many, then asserts the API calls the data cache and never touches the default cache — this is the precise condition POST /api/v1/cachekey/invalidate doesn't delete Redis entries when DATA_CACHE_CONFIG uses a different CACHE_KEY_PREFIX than CACHE_CONFIG #40489 fails on in production.Manual reproduction (per the issue)
redis-cli EXISTS superset_data_<hash>→1.POST /api/v1/cachekey/invalidate {"datasource_uids":["<uid>"]}→201.redis-cli EXISTS superset_data_<hash>→ still1(chart serves stale data).redis-cli EXISTS superset_data_<hash>→0(chart re-runs fresh query).ADDITIONAL INFORMATION