GitHub user bsethi24 edited a discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?
We are deploying Apache Superset 6.1.0 and validated the live runtime behavior. Current runtime: - CACHE CONFIG- NullCache - DATA CACHE CONFIG = NullCache - FILTER STATE CACHE CONFIG = SupersetMetastoreCache - EXPLORE FORM DATA CACHE CONFIG = SupersetMetastoreCache - RESULTS BACKEND = None - no Redis configured - no Memcached configured So the current deployment is not using an external shared cache backend. However, Superset 6.1 still appears to require flask-caching in the dependency set. We want to confirm whether this is still expected even when runtime uses only NullCache and SupersetMetastoreCache. We observed Flask-Caching versions blocked in our mirror with 403 (quarantined due to vulnerabilities) for multiple Flask-Caching 2.x releases, which is why we are trying to understand whether the dependency is structurally required or whether there is any supported way to avoid it. As its blocker for Superset 6.1.0 image creation. Questions: 1. Is flask-caching still an expected dependency for Superset 6.1 in this runtime model? 2. Is SupersetMetastoreCache still implemented through Flask-Caching abstractions? 3. Is there any supported way to avoid this dependency while staying on Superset 6.17 4. If Redis or Memcached is needed later for scale or distributed coordination, what is the recommended secure configuration pattern? Blocked versions observed in our mirror path: 2.5.1 2.5.0 2.4.1 2.4.0 2.3.1 2.3.0 2.2.0 2.1.0 2.0.2 We are trying to separate 1 current runtime behavior 2. dependency/build behavior 3. future Redis/Memcached use cases 4. GitHub link: https://github.com/apache/superset/discussions/44823 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
