Apache Superset Error on SQL Lab screen "The database that was used to generate this query could not be found"

Bug description

Reproduction steps: 1. Run Superset with "docker compose" on macbook 2. Login to Settings -> Database connections and add mysql database named MySQL 3. Go to "SQL Lab" , select postgres database "examples" , select schema "public", select any table and run test query on that, it is SUCCESS. 4. Go to "SQL Lab" , select newly added mysql database "MySQL" , ERROR appears 5. "SQL Lab" , select postgres database "examples" , select schema "public" (which was success in step 3) ERROR 6. Once the ERROR appears none of the Databases work, the only options is to Logout and Login again.

I tried the same steps with Clickhouse DB as well with same results. So behaviour is not mysql specific.

Screenshots/recordings

Error on Step 4

Error on Step 5

Superset version

5.0.0

Python version

3.9

Node version

Browser

Safari

Additional context

Post Step 4 Logs from container "superset_app" Main errors: "GET /api/v1/database/mysql-MySQL-5/function_names/ HTTP/1.1" 404 - "PUT /tabstateview/3 HTTP/1.1" 400 -

2025-07-11 10:24:02 2025-07-11 04:54:02,908:WARNING:superset.views.error_handling:HTTPException 2025-07-11 10:24:02 Traceback (most recent call last): 2025-07-11 10:24:02 File "/app/.venv/lib/python3.11/site-packages/flask/app.py", line 1484, in full_dispatch_request 2025-07-11 10:24:02 rv = self.dispatch_request() 2025-07-11 10:24:02 ^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-11 10:24:02 File "/app/.venv/lib/python3.11/site-packages/flask/app.py", line 1458, in dispatch_request 2025-07-11 10:24:02 self.raise_routing_exception(req) 2025-07-11 10:24:02 File "/app/.venv/lib/python3.11/site-packages/flask/app.py", line 1440, in raise_routing_exception 2025-07-11 10:24:02 raise request.routing_exception # type: ignore 2025-07-11 10:24:02 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-11 10:24:02 File "/app/.venv/lib/python3.11/site-packages/flask/ctx.py", line 353, in match_request 2025-07-11 10:24:02 result = self.url_adapter.match(return_rule=True) # type: ignore 2025-07-11 10:24:02 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-11 10:24:02 File "/app/.venv/lib/python3.11/site-packages/werkzeug/routing/map.py", line 629, in match 2025-07-11 10:24:02 raise NotFound() from None 2025-07-11 10:24:02 werkzeug.exceptions.NotFound: 404 Not Found: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again. 2025-07-11 10:24:02 2025-07-11 04:54:02,910:INFO:werkzeug:192.168.65.1 - - [11/Jul/2025 04:54:02] "GET /api/v1/database/mysql-MySQL-5/function_names/ HTTP/1.1" 404 - 2025-07-11 10:24:07 2025-07-11 04:54:07,914:INFO:werkzeug:192.168.65.1 - - [11/Jul/2025 04:54:07] "PUT /tabstateview/3 HTTP/1.1" 400 - 2025-07-11 10:24:20 2025-07-11 04:54:20,476:INFO:werkzeug:192.168.65.1 - - [11/Jul/2025 04:54:20] "GET /api/v1/me/ HTTP/1.1" 200 -

Logs from superset_nginx 2025-07-11 10:24:02 192.168.65.1 - - [11/Jul/2025:04:54:02 +0000] "GET /api/v1/database/mysql-MySQL-5/function_names/ HTTP/1.1" 404 264 [1] "http://localhost/sqllab/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Safari/605.1.15" "-" 2025-07-11 10:24:07 192.168.65.1 - - [11/Jul/2025:04:54:07 +0000] "PUT /tabstateview/3 HTTP/1.1" 400 983 [2] "http://localhost/sqllab/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Safari/605.1.15" "-"

Post Step 5

Logs from container "superset_app" post Step 5 Main Errors "GET /api/v1/database/postgresql-examples-1/function_names/ HTTP/1.1" 404 - "PUT /tabstateview/3 HTTP/1.1" 400 - 2025-07-11 10:25:52 2025-07-11 04:55:52,069:WARNING:superset.views.error_handling:HTTPException 2025-07-11 10:25:52 Traceback (most recent call last): 2025-07-11 10:25:52 File "/app/.venv/lib/python3.11/site-packages/flask/app.py", line 1484, in full_dispatch_request 2025-07-11 10:25:52 rv = self.dispatch_request() 2025-07-11 10:25:52 ^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-11 10:25:52 File "/app/.venv/lib/python3.11/site-packages/flask/app.py", line 1458, in dispatch_request 2025-07-11 10:25:52 self.raise_routing_exception(req) 2025-07-11 10:25:52 File "/app/.venv/lib/python3.11/site-packages/flask/app.py", line 1440, in raise_routing_exception 2025-07-11 10:25:52 raise request.routing_exception # type: ignore 2025-07-11 10:25:52 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-11 10:25:52 File "/app/.venv/lib/python3.11/site-packages/flask/ctx.py", line 353, in match_request 2025-07-11 10:25:52 result = self.url_adapter.match(return_rule=True) # type: ignore 2025-07-11 10:25:52 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-11 10:25:52 File "/app/.venv/lib/python3.11/site-packages/werkzeug/routing/map.py", line 629, in match 2025-07-11 10:25:52 raise NotFound() from None 2025-07-11 10:25:52 werkzeug.exceptions.NotFound: 404 Not Found: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again. 2025-07-11 10:25:52 2025-07-11 04:55:52,074:INFO:werkzeug:192.168.65.1 - - [11/Jul/2025 04:55:52] "GET /api/v1/database/postgresql-examples-1/function_names/ HTTP/1.1" 404 - 2025-07-11 10:25:57 2025-07-11 04:55:57,067:INFO:werkzeug:192.168.65.1 - - [11/Jul/2025 04:55:57] "PUT /tabstateview/3 HTTP/1.1" 400 - 2025-07-11 10:26:21 2025-07-11 04:56:21,655:INFO:werkzeug:127.0.0.1 - - [11/Jul/2025 04:56:21] "GET /health HTTP/1.1" 200 -

Logs from superset_nginx 2025-07-11 10:25:52 192.168.65.1 - - [11/Jul/2025:04:55:52 +0000] "GET /api/v1/database/postgresql-examples-1/function_names/ HTTP/1.1" 404 264 [2] "http://localhost/sqllab/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Safari/605.1.15" "-" 2025-07-11 10:25:57 192.168.65.1 - - [11/Jul/2025:04:55:57 +0000] "PUT /tabstateview/3 HTTP/1.1" 400 999 [1] "http://localhost/sqllab/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Safari/605.1.15" "-"

Checklist

[x] I have searched Superset docs and Slack and didn't find a solution to my problem.
[x] I have searched the GitHub issue tracker and didn't find a similar bug report.
[x] 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.

Comment From: dosubot[bot]

Hi @msshroff! I'm Dosu and I’m helping the superset team.

This is a known bug in Superset's SQL Lab state management. When you switch databases, sometimes the frontend stores the database ID as a string (like mysql-MySQL-5 or postgresql-examples-1) instead of a numeric ID. This causes all subsequent API calls for any database to fail with 404 errors, breaking SQL Lab for all databases until you reload or log out and back in. The backend expects a numeric database ID, so when it receives a string, it can't find the database and returns a 404. This also explains the 400 errors on /tabstateview/—the backend can't insert the invalid database ID into the tab state model, so it rejects the request.

This bug is not specific to MySQL or Clickhouse; it can happen with any database if the frontend state gets corrupted. There is no robust recovery except to reload or log out/in, which resets the frontend state and restores functionality. Defensive type checking is needed on both the frontend and backend to prevent this, but as of now, no fix has landed in recent releases or PRs. More details and similar reports are discussed here.

For now, if you hit this state, reload the page or log out and back in to reset SQL Lab. Avoid using non-standard or slug-like database names if possible, and keep an eye on future releases for a fix.

To reply, just mention @dosu.

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

Comment From: msshroff

Thanks @dosu.

But because of this error I am not able to access the newly added MySQL or Clickhouse DBs in the SQL Lab at all. As soon i select anything other that "examples" database this error appears.

Is there are workaround for that?

Comment From: dosubot[bot]

There’s a built-in workaround that can help: in SQL Lab, append ?reset=1 to the URL (so it looks like .../sqllab/?reset=1). This will show a “Reset state” button in the left sidebar—clicking it will fully reset SQL Lab’s state, clearing out any corrupted data and restoring database access. Note that this will close all open tabs and discard any unsaved queries or work, so save anything important first.

This is currently the only reliable way to recover from this bug until the upstream fix is merged and released (details).

To reply, just mention @dosu.

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