Grafana 13.2 Panels do not refresh according to tab-variables after switching dashboard tabs

My Grafana version is V13.2.
I have a problem with a dashboard that contains 2 tabs (new grafana Tabs).
In Tab1 I have two panels. 1st panel has a mySQL-datasource. 2nd panel uses a datasource of type ‘-- Dashboard --’ which is linked to the 1st panel’s datasource.
On top of Tab1 I have a tab-variable to filter the data by user.
The problem is if I switch to Tab2 and back to Tab1 and further change the tab-variable only the 1st panel refreshs the data. The 2nd one, which uses data from 1st panel does not!
It seems that Grafana looses the database connection of the 2nd panel to the data of the 1st panel after moving forth and back the Grafana tabs.

Is there any solution?

Hi @acdeveloperit1,

This smells like a panel-unmount problem rather than anything specific to
your variable. The -- Dashboard -- datasource works by subscribing to the
source panel’s query runner. When a panel leaves the viewport — collapsed
rows historically, and now tabs — Grafana can unmount it, and the dependent
panel’s subscription isn’t always re-established when it comes back. The
source panel re-runs on the variable change; the dependent panel just never
hears about it.

A few things that would confirm or kill that theory:

  1. Does hitting the dashboard refresh button fix the panel, or does it stay
    stale until a full page reload? (Refresh fixing it → the subscription is
    alive and only the variable change failed to propagate. Only a reload
    fixing it → the subscription is genuinely gone.)
  2. Do you get the same behaviour with the two panels in a collapsed row
    instead of tabs, expanding and collapsing it? If yes, this is the general
    unmount path and not a tabs-specific bug.
  3. On the broken panel, Panel inspect → Data: no data at all, or stale data
    with an old timestamp?
  4. Self-hosted or Cloud? And was this dashboard created on the new dashboard
    schema, or migrated from an older one?

Workaround in the meantime: point the second panel straight at MySQL with the
same query instead of using the Dashboard datasource. You pay for a second
query, but it re-runs on variable changes reliably. If avoiding that duplicate
query was the reason you reached for the Dashboard datasource, mention it —
there may be a better option.

This is a Grafana refresh issue with the -- Dashboard -- datasource, not a MySQL connection problem.

The behavior you describe matches a known issue: when the variable changes, the source panel refreshes but a panel using -- Dashboard -- doesn’t get updated.

Try clicking the dashboard Refresh button after changing the variable. If that doesn’t work, try a full page reload.

As a workaround, you can avoid -- Dashboard -- for the second panel and query the MySQL datasource directly with the required query/logic. This means running the query separately, but the panel will participate in the normal variable refresh.

If the second panel must consume the first panel’s results, the refresh/page-reload workaround is the practical option until the underlying issue is fixed.

Hi @infofcc3 @fozmenfurkan thanks for reply. I also thought about using same query in other panels of same tab. But in some tabs I have 10 smaller panels or KPIs which then need to refresh data from mySQL server - this is not as performant as expected.
What I found out is that switching off ‘Transform’ and ‘Filters’ in the panels which use the ‘-- Dashboard --’ query solved the problem for me.
The only issue then is I had to add transformations (e.g. grouping, filtering by tab/dashboard variables, etc.) in each target panel - but it was worth it!

Hopefully this could be solved by grafana developers in one of next releases.

Thanks for sharing this very useful, especially since re querying MySQL for 10 KPI panels per tab would add unnecessary database load.

There is a Grafana issue with very similar behavior:

where a panel using -- Dashboard -- does not update when a dashboard variable changes, while the referenced panel does. The issue is marked as Done, but the reported behavior is very similar to what you’re seeing.

Your Transform/Filters workaround is therefore a useful workaround for now, particularly when you want to avoid running the MySQL query separately for every KPI panel.

Hopefully the same refresh behavior can be handled correctly in a future Grafana release.