12 lines
1.4 KiB
Markdown
12 lines
1.4 KiB
Markdown
# Dashboards should refresh when the rest of the UI refreshes
|
|
|
|
`App.tsx` polls logs/timeline every `POLL_MS` (2000ms — `src/App.tsx`) and, for rolling range presets, recomputes `range.startMs`/`range.endMs` on each tick. Dashboard panels (`PanelPreview` in `Dashboards.tsx`) only refetch their PromQL series when `panel.promql`, `panel.chart_type`, `range.startMs`, or `range.endMs` change (`useEffect` dependency array, `Dashboards.tsx` ~line 78). So a dashboard panel only refreshes if the rolling range's bounds actually move; with a fixed/absolute range selected, or between rolling-preset ticks where the resolved bounds happen not to change, panels go stale even though the rest of the UI (log table, timeline) is actively re-polling.
|
|
|
|
Dashboards should refresh on the same cadence as the rest of the app, not only when their `range` prop happens to change value.
|
|
|
|
## Acceptance criteria
|
|
- Dashboard panels (`PanelPreview`, and by extension `AllDashboardsView`) refetch their PromQL series on the same polling cadence as `App.tsx`'s log/timeline polling, independent of whether `range.startMs`/`range.endMs` literally changed.
|
|
- This applies both to the normal `Dashboards` section and the popped-out dashboard view, if it polls independently.
|
|
- No duplicate/overlapping fetches are introduced (e.g. a range change and the periodic tick firing at the same time shouldn't double-fetch).
|
|
- Existing refetch-on-range/query/chart-type-change behavior is preserved.
|