royspeedy commented on issue #42123:
URL: https://github.com/apache/superset/issues/42123#issuecomment-5010674592
@dosu
I’ve narrowed this down to a SQL Lab error classification problem inside
Superset rather than a PostgreSQL authentication or connectivity issue.
What has been verified
security_manager.find_user('admin') returns the active user correctly.
SELECT username, active FROM ab_user shows admin is active.
/api/v1/me/ returns 200 in the web pod, so the session and current user
context are valid.
get_sqla_engine() works in superset shell.
get_raw_connection(..., source=QuerySource.SQL_LAB) also works in superset
shell.
PostgreSQL logs show no connection attempt when SQL Lab fails.
allow_run_async = False, so this is not the async/Celery worker path.
The runtime app config is correct:
SQLALCHEMY_DATABASE_URI matches the expected metadata DB
SECRET_KEY matches the expected secret
What the logs show
SQL Lab request processing reaches:
Triggering query_id
Set query to 'running'
Running block 1 out of 1
Storing results in results backend
Then it fails in:
superset/sqllab/sql_json_executer.py:110
The exception surfaced to the user is:
invalid username-password pair or user is disabled.
with SupersetErrorType.GENERIC_DB_ENGINE_ERROR and issue code 1002.
Why this looks misleading
The message looks like an authentication failure, but all evidence shows:
user lookup is fine
metadata DB access is fine
runtime config is fine
target PostgreSQL is never reached
the actual exception is being swallowed and reclassified by Superset
So the problem appears to be that Superset is mapping a deeper SQL Lab
execution failure to a generic PostgreSQL auth-like error, instead of exposing
the real root cause.
Environment notes
Superset version: 6.1.0
Deployed on Kubernetes via Helm
Custom image: my-superset:latest
CUSTOM_SECURITY_MANAGER was tested and removing it did not change the issue
RESULTS_BACKEND is configured
No Celery worker pod is present
Suggested next step
The most useful next step is to expose the original exception inside
sql_json_executer.py / SQL Lab execution flow, because the current message is
hiding the true failure source.
--
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]
