drnkenmonkey opened a new issue, #42319:
URL: https://github.com/apache/superset/issues/42319
### Bug description
`DASHBOARD_VIRTUALIZATION_DEFER_DATA` does not defer chart data queries on
initial dashboard load, even though it's correctly enabled and dashboard
virtualization is active.
Expected: with `DASHBOARD_VIRTUALIZATION_DEFER_DATA=True` (and
`DASHBOARD_VIRTUALIZATION=True`), charts outside the initial viewport (+
render-ahead margin) should not fire their `/api/v1/chart/data` query until
scrolled into view.
Observed: every chart on the dashboard fires its data query immediately on
page load, regardless of scroll position. Confirmed via a Playwright test
counting `POST /api/v1/chart/data` requests before and after scrolling to the
bottom of a 26-chart, ~6100px-tall dashboard (900px viewport) — identical count
(32/32) in both cases, across three separate attempts.
### How to reproduce
1. Enable both flags in `superset_config.py`:
```python
FEATURE_FLAGS = {
"DASHBOARD_VIRTUALIZATION": True,
"DASHBOARD_VIRTUALIZATION_DEFER_DATA": True,
}
```
2. Load a dashboard tall enough that a meaningful fraction of its charts
start out beyond the render-ahead margin (~1 viewport height below the fold).
3. Watch network requests to `/api/v1/chart/data` on initial load — all
charts' queries fire immediately.
### Investigation
Confirmed the flags reach both the backend (`app.config['FEATURE_FLAGS']`)
and the frontend bootstrap payload (`data-bootstrap` on `#app`) correctly, so
this isn't a config propagation issue.
Traced the actual gating logic in the built frontend bundle. The relevant
chart-container code is (from a production build, so exact naming here comes
from the mangled bundle, mapped back to
`superset-frontend/src/components/Chart/Chart.jsx`'s general shape):
```js
runQuery(){
(!(0,m.G7)(m.TO.DashboardVirtualizationDeferData)||this.shouldRenderChart())&&this.props.actions.postChartFormData(...)
}
shouldRenderChart(){
return
this.props.isInView||!(0,m.G7)(m.TO.DashboardVirtualization)||(0,_.a)()
}
```
So when `DEFER_DATA` is on, the initial query only fires if
`shouldRenderChart()` is true, which in turn depends on `this.props.isInView`.
Ruled out "the dashboard is just short enough that everything's already
within the render-ahead margin" directly with real numbers: dashboard height
6126px vs. a 900px viewport and (per the original virtualization PR's
documented behavior) a ~1-viewport-height render-ahead margin — well under half
the page should be considered "in view" at scroll position 0. Instead, 100% of
charts fire their query immediately.
Best guess at the mechanism: `isInView` appears to default to `true` (or is
otherwise not yet populated by the `IntersectionObserver`) at the moment a
chart component first mounts, and `runQuery()` runs synchronously during that
same mount — before the observer's first callback has a chance to report the
chart as off-screen. If so, the *initial* load of every chart bypasses the
deferral entirely; only later `isInView` transitions triggered by actual
scrolling would ever reflect real position, but per the "rerendering charts do
NOT trigger new queries" behavior documented for the base virtualization
feature, a later `isInView` flip wouldn't retroactively cancel/refire the query
anyway.
### Environment
- Superset version: 6.1.0 (current latest stable at time of testing)
- Installed via: custom Docker image (`apache/superset:6.1.0` base +
`psycopg2-binary` + `clickhouse-connect`), self-hosted docker-compose
- Python: 3.10
- Database: ClickHouse (not likely relevant to this bug, included for
completeness)
- Browser: Chromium via Playwright (headless), also observed the same
immediate-fetch behavior via manual testing in Chrome
--
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]
