royspeedy commented on issue #42123:
URL: https://github.com/apache/superset/issues/42123#issuecomment-5010814335
Update on root cause:
I confirmed the SQL query itself was succeeding, and the failure happened
later when Superset tried to store SQL Lab results in the results backend.
What I observed:
- The log sequence was: “Running block 1 out of 1” → “Storing results in
results backend” → failure.
- Inside `superset shell`, `results_backend` was a `RedisCache` object.
- Calling `results_backend.set("test_key", b"test_value")` and
`results_backend.get("test_key")` initially failed with:
`redis.exceptions.AuthenticationError: invalid username-password pair or
user is disabled.`
- A direct `redis-cli` test from inside the cluster showed that Redis
authentication itself was valid.
- Inspecting the runtime config showed that `CACHE_CONFIG` pointed to Redis
DB 1, but the actual `RESULTS_BACKEND` client was instantiated against Redis DB
0.
The key detail was that `RESULTS_BACKEND` was not using the same Redis DB as
the cache config. In my Helm values, cache was configured for DB 1, while the
runtime results backend was resolving to DB 0. This caused SQL Lab result
storage to fail and surface as a misleading database authentication error.
I fixed it by explicitly setting `RESULTS_BACKEND` in
`configOverrides.cache` to use the same Redis host/password and `db=1`:
```python
from flask_caching.backends.rediscache import RedisCache
RESULTS_BACKEND = RedisCache(
host="my-redis-master.databases.svc.cluster.local",
port=6379,
password=_redis_pass,
db=1,
key_prefix="superset_results",
default_timeout=300,
)
```
After redeploying with Helm:
- `vars(current_app.config["RESULTS_BACKEND"])` now shows both the read and
write clients using `db=1`.
- `results_backend.set("test_key", b"test_value")` returns `True`.
- `results_backend.get("test_key")` returns `b"test_value"`.
So the root cause is resolved: SQL Lab was failing during results backend
storage because the runtime `RESULTS_BACKEND` Redis client was pointing to the
wrong Redis DB. The PostgreSQL-like auth error was a misleading symptom of that
misconfiguration.
--
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]
