Not able to run any SQL query on SQL lab

[ABDevops-test]

Bug description

I have created a connection to StarRocks in Apache Superset using the StarRocks dialect. However, when I try to run an SQL query (even a simple SELECT) in Superset’s SQL Lab, I get an “authentication required” error — indicating an issue with the StarRocks database connection. Database connection is already successfully connected and able to see tables created in starrocks but not able to run any query on it.
Can anyone please help here?

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot[bot]]

Hi @ABDevops-test! I'm Dosu and I’m helping the superset team.

This issue is likely caused by how Superset handles impersonation for StarRocks connections during query execution. When running queries in SQL Lab, Superset may execute a pre-query like EXECUTE AS "username" WITH NO REVERT; if impersonation is enabled for the database connection. If the impersonation fails or the effective user lacks privileges, StarRocks returns an "authentication required" error, even though listing tables works (because metadata operations skip this step) [source].

Here’s a checklist to help resolve this:

1. Check impersonation settings: In Superset, go to your StarRocks database connection and see if "Impersonate the logged-in user" is enabled. If so, try disabling it and test query execution again.
2. Verify user privileges: Make sure the user specified in your connection string has permission to run queries and, if impersonation is enabled, that the impersonated user can run queries in StarRocks.
3. Review connection string: Confirm your connection string follows the format starrocks://<User>:<Password>@<Host>:<Port>/<Catalog>.<Database> and that credentials are correct [source].
4. Driver compatibility: If you installed the latest StarRocks driver, there may be a SQLAlchemy version conflict. Use starrocks==1.0.6 to ensure compatibility with Superset [source].
5. Check logs: Look for detailed error messages in both Superset and StarRocks logs to pinpoint whether the failure is during the impersonation pre-query or the main query.

If impersonation is not needed, disabling it is often the quickest fix. If you need impersonation, ensure the StarRocks user has the right privileges and that the pre-query works when run manually. For more details, see the StarRocks Superset integration docs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[ABDevops-test]

@dosu
The impersonation setting is already disabled. I have also verified on my local machine via terminal that the queries run successfully — only Superset is having an issue executing the same.

[dosubot[bot]]

Since impersonation is disabled and queries work in your terminal but not in Superset, the issue is likely with Superset’s connection configuration or environment. Here are the most common causes and next steps:

• Driver compatibility: Superset requires sqlalchemy==1.4.54, but the latest StarRocks adapter needs SQLAlchemy v2, which can cause authentication or query execution errors. Make sure you’re using starrocks==1.0.6 for the driver in your Superset environment to avoid this conflict source.
• Connection string and SSL settings: Double-check that your Superset connection string matches the one you use in your terminal, including any SSL or root certificate options. In Superset, these should be set either in the SQLAlchemy URI or in the Extra JSON as engine_params.connect_args (for example: {"engine_params": {"connect_args": {"sslmode": "require", "sslrootcert": "https://github.com/path/to/cert.pem"}}}) source.
• Endpoint configuration: If Superset is pointed at a read-only StarRocks endpoint or proxy, even SELECT queries can fail with authentication or permission errors. Make sure the endpoint allows reads and matches what you use in your terminal source.
• Environment-specific issues: If you’re running Superset in Kubernetes or with Helm, missing Redis password configuration can cause authentication errors in SQL Lab, even if the database credentials are correct. Check your Helm chart’s values.yaml for Redis password settings if applicable source.

If you share your Superset connection string, Extra JSON, and the exact driver versions, I can help spot any mismatches. Also, check Superset and StarRocks logs for more detailed error messages—they often pinpoint where authentication is failing.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[ABDevops-test]

Below is the starrocks driver version

connection string
starrocks://username:XXXXXXXXXX@starrocks-sd.test.dll.aadpace.com:9030/

[dosubot[bot]]

Your StarRocks driver version (1.2.2) is not compatible with Superset’s required SQLAlchemy version (1.4.54). This mismatch can cause authentication errors when running queries, even if the connection appears successful and tables are visible. The recommended fix is to downgrade the StarRocks driver to version 1.0.6, which works with SQLAlchemy 1.4.54 and resolves these issues source.

Also, make sure your connection string follows the format starrocks://<User>:<Password>@<Host>:<Port>/<Catalog>.<Database>—catalog and database must be separated by a dot source.

If you still see errors after downgrading, check your Superset database “Extra” JSON for any SSL or authentication options, and confirm your endpoint isn’t a read-only replica. If you want, share your Extra JSON and the full connection string (with sensitive info redacted) for a more detailed review.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[rusackas]

Hopefully the bot is right, and that resolves it. Let us know if not!

[ABDevops-test]

I did install StarRocks driver to version 1.0.6 as per below. But still issue persists. Please suggest.

[ABDevops-test]

@rusackas
Kindly help on above as issue still persists. Also, we are facing same issue with postgresql database connection.

[ABDevops-test]

@rusackas @dosu

Kindly check above comments and let me know if anything i can do from my end.

@rusackas
Also let me know if there is any possibility of having a call for discussion on this so that we can resolve the issue in minimal time.

[sfirke]

Hello @ABDevops-test in a way it's nice that you're having the trouble with Postgres too since that shifts the focus from "some edge case related to StarRocks" to a general config problem. Superset definitely works with Postgres, that's what we test CI with. So I'd keep focusing on debugging that connection instead of StarRocks.

Also I see you marked that you're running the master branch, which could be unstable. If that's true, instead try to debug with e.g. 6.0.0rc4 which is not officially released but has been nice and stable in my testing.

[lilotter45]

@ABDevops-test, I also have a StarRocks database connection configured and working. I can give you some information on the configuration I've used as a point of reference:

Version

I'm running 5.0.0 and 6.0.0rc2 or maybe rc3 with these settings. I do have a custom build that I'm using.

StarRocks is version 3.4.4-bc987bb

Dockerfile

This is the Dockerfile I use to build the image I'm using, minus some customizations and packages irrelevant to this issue. It is based on the example in the docs.

ARG SUPERSET_TAG=5.0.0
FROM apache/superset:${SUPERSET_TAG}

USER root

# Set environment variable for Playwright
ENV PLAYWRIGHT_BROWSERS_PATH=/usr/local/share/playwright-browsers

# Add build-essential to allow building python packages
RUN /app/docker/apt-install.sh build-essential default-libmysqlclient-dev pkg-config

# Install packages using uv into the virtual environment
RUN . .venv/bin/activate && \
    uv pip install --no-cache-dir \
    authlib \
    flask-caching \
    mysqlclient \
    pillow \
    playwright \
    psycopg2-binary \
    redis \
    starrocks==1.2.2 \
    && playwright install-deps \
    && PLAYWRIGHT_BROWSERS_PATH=/usr/local/share/playwright-browsers playwright install chromium

USER superset

CMD ["https://github.com/app/docker/entrypoints/run-server.sh"]

Python packages I have explicitly added that are relevant to StarRocks:

• mysqlclient
• starrocks - use version 1.2.2 because 1.2.3 is broken; a fix was just released a couple days ago, but it isn't yet available, except when built from source

StarRocks

• Is it possible that you have a permission issue for the user that you've used to connect? Are you able to run a SELECT query in other clients using the same credentials?
• If not, maybe you need to grant SELECT privileges, e.g.:

-- If you're providing permissions via roles, you might need/want to make sure they're applied at login, or you can set the default role, as I've done below.
SET GLOBAL activalte_all_roles_on_login = TRUE;

CREATE DATABASE example_db;

SET CATALOG default_catalog;

CREATE ROLE IF NOT EXISTS reader;

GRANT SELECT ON ALL TABLES IN DATABASE example_db TO ROLE reader;

CREATE USER test_user IDENTIFIED BY 'some-password' DEFAULT ROLE reader;

[sfirke]

Thanks @lilotter45, that's helpful context and additional info for future readers!

Given that this seems not to be reproducible, I'm going to convert this to a discussion. @ABDevops-test if you're able to provide additional information that allows others to reproduce this and verify that indeed there's a bug in the Superset codebase that needs fixing, we'll chat here and then open a new, more specific report with the actual bug documented.