angrymango opened a new issue, #43552:
URL: https://github.com/apache/superset/issues/43552
### Bug description
A chart whose datasource is a **SIP-182 semantic view** (`datasource_type:
"semantic_view"`) renders correctly in Explore but never renders on a
dashboard. The tiles sit at *"Waiting on database…"* and every native filter
shows *"Network error"*.
The cause is in the dashboard's datasource bootstrap, not in the chart.
`Dashboard.datasources` is built from each slice's `datasource`, and
`Slice.datasource` is the SQLA-table relationship:
```python
# superset/models/slice.py:186
@property
def datasource(self) -> SqlaTable | None:
return self.table
# superset/models/dashboard.py:271
@property
def datasources(self) -> set[BaseDatasource]:
return {slc.datasource for slc in self.slices if slc.datasource}
```
A semantic-view slice has no `table`, so it contributes nothing. `GET
/api/v1/dashboard/<id>/datasets` therefore returns `[]` even though the
dashboard's charts are correctly related to it (`GET
/api/v1/dashboard/<id>/charts` returns them, with `form_data.datasource ==
"1__semantic_view"`), and the tile's data request is then made against
**`datasource_type: table`**.
**Steps to reproduce**
1. Enable `FEATURE_FLAGS = {"SEMANTIC_LAYERS": True}` and register a SIP-182
semantic layer implementation.
2. Create a semantic view (`POST /api/v1/semantic_view/`).
3. Create a chart bound to it — `datasource_type: "semantic_view"`,
`datasource_id: <view id>`, `params.datasource: "<view id>__semantic_view"`.
4. Confirm the chart works in Explore: it renders, and `POST
/api/v1/chart/data` with `{"datasource": {"id": <id>, "type": "semantic_view"},
…}` returns rows.
5. Create a dashboard whose `position_json` places that chart, and relate
the two (`PUT /api/v1/chart/<id> {"dashboards": [<dashboard id>]}`).
6. Open the dashboard.
**Expected:** the tile renders the same chart Explore renders.
**Actual:** the tile never loads. Server log:
```
WARNING:superset.daos.datasource:Datasource not found datasource_type:
table, database_id_or_uuid: 1
"POST /api/v1/chart/data?form_data={"slice_id":1}&dashboard_id=1 HTTP/1.1"
400
"POST /api/v1/chart/data HTTP/1.1" 404 # the native filters' member
lists
"GET /api/v1/dataset/1/drill_info/?q=(dashboard_id:1) HTTP/1.1" 404
```
and `GET /api/v1/dashboard/<id>/datasets` → `{"result": []}`.
Note the datasource type in that warning is `table`, not `semantic_view` —
nothing in the dashboard payload tells the client otherwise.
**Related, possibly the same fix:** `GET /api/v1/dashboard/<id>/datasets` is
not the only place a semantic view is invisible. There is also no endpoint that
lists semantic views with their ids — `GET /api/v1/semantic_view/` is a 405
(the resource exposes `POST /`, `PUT`/`DELETE /<pk>`, `GET /<pk>/structure`),
and `POST /api/v1/semantic_layer/<uuid>/views` returns names without ids — so
automation that creates charts has to discover the integer id by probing
`/<pk>/structure`. Happy to open that separately if it is a distinct concern.
### Screenshots/recordings
Dashboard: the layout, titles and both native filters are correct; the tiles
stay empty and the filters read "Network error". The same chart opened at
`/explore/?slice_id=<id>` renders normally with real data.
### Superset version
master / latest-dev (`1fd763b`, 2026-08-26)
### Python version
3.11
### Node version
18 or greater
### Browser
Chrome
### Additional context
- Feature flags: `SEMANTIC_LAYERS: True`. Source install of `master`, SQLite
metadata DB, frontend assets built from the same checkout.
- The semantic layer is an in-house implementation of the `superset_core`
SIP-182 protocol. The behaviour above is independent of it: the chart is stored
correctly, and the same query succeeds when the datasource is named explicitly
in the request body — it is only the dashboard path that loses the type.
- No Python stacktrace; the failure is the `Datasource not found` warning
above plus a 400 from `/api/v1/chart/data`.
- Refs SIP-182 (#35003).
### 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.
--
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]
