[Bug]: Infinite rendering loop and NS_BINDING_ABORTED on Force Refresh in Dashboards with Nested Tabs (v6.0.0)

[saulojb]

Bug description

Description:
In Apache Superset 6.0.0, dashboards containing nested tabs (tabs within tabs) enter an infinite re-render loop when a manual "Force Refresh" is triggered. This behavior was not present in version 4.0.0.
When clicking the refresh button, the frontend (React) repeatedly cancels and restarts chart requests, leading to high CPU usage and browser instability.
Steps to Reproduce:
Create or migrate a dashboard to Superset 6.0.0.
Structure the dashboard using Nested Tabs (e.g., a top-level Tab component containing another Tab component inside).
Place several charts within these nested tabs.
Click on the dashboard's "Force Refresh" button (top right menu).
Observe the charts flickering and entering a continuous loading/reloading cycle.
Expected Behavior:
All charts should refresh once, regardless of their position in the tab hierarchy.

Screenshots/recordings

Superset version

master / latest-dev

Python version

3.11

Node version

18 or greater

Browser

Chrome

Additional context

No response

Checklist

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

[dosubot]

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

This is a known bug in Superset 6.0.0: dashboards with nested tabs can enter an infinite rerender loop and cause repeated chart request cancellations (NS_BINDING_ABORTED) when you use the manual "Force Refresh" button. Auto-refresh works fine because it uses a different code path. The root cause is a frontend issue with how refreshes are dispatched for nested tabs.

A fix was merged on 2026-01-10 (PR #37018), which adds a "lazy" refresh option and prevents the infinite loop by tracking handled refreshes in nested tabs. This fix is available in the master/latest-dev branch after that date and will be included in the next release (6.0.1 or later)source.

To resolve the issue, update your deployment to a commit after 2026-01-10 or wait for the next official release. As a workaround, avoid using manual refresh on dashboards with nested tabs, use auto-refresh instead, or temporarily restructure dashboards to remove nested tabssource.

To reply, just mention @dosu.

---

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

   

[VaibhavNarayann]

Hey there! I’d like to work on this issue.

[saulojb]

Hi, I saw on (#37018) that there was a fix for the front-end, so I downloaded the brand master and recompiled the front-end and replaced the assets from the official version with this newly compiled one. But there was no change in the symptoms.

[cobyoo]

When will 6.0.1 be released?

[saulojb]

[saulojb]

Solved !!!

Summary

Updates to avoid timeouts and an infinite refresh loop: added a staggered interval to forced dashboard refreshes and fixed a Tab effect that retriggered refreshes.

Files changed

• index.jsx
• Tab.jsx

What I changed

• index.jsx

  • Added staggerInterval (from dashboardInfo.metadata.stagger_time, falling back to 5000ms).
  • Logged interval: staggerInterval.
  • Call onRefresh(chartIds, true, staggerInterval, dashboardInfo.id) so forced refreshes are staggered instead of all firing at once.

• Tab.jsx

  • Removed lastRefreshTime from the useEffect dependency list that triggers refresh when a tab becomes visible.
  • Added a comment and an eslint-disable-next-line react-hooks/exhaustive-deps to prevent re-running the effect when lastRefreshTime updates (this previously caused an infinite refresh loop).

Why

• force=true without staggering triggers many cache-bypassing queries simultaneously, increasing the chance of server timeouts/errors.
• The Tab effect reacted to lastRefreshTime updates and re-fired onRefresh, creating a loop. Avoiding that dependency prevents re-triggering while preserving the intended initial refresh behavior.

https://drive.google.com/file/d/1_j6Z9D72mYOd2AANqn0qBQaRvDvEX2UM/view?usp=sharing
Compiled version -> assets.zip, replace in the superset/static/ folder

[rusackas]

@saulojb did you (or would you) open a PR witht hose changes?

@dosu does that seem like the right fix for this?

[dosubot]

No, there isn't a PR open with @saulojb’s changes as of now.

About the fix: PR #37018 is the main solution for the infinite refresh loop in nested tabs—it uses a handledRefreshRef and an isLazyLoad flag to prevent duplicate refreshes when tabs become visible after a dashboard refresh, and regression tests confirm it works as intended source.

Your staggered forced refresh approach (spreading chart refreshes over time) isn’t part of the current codebase, but it could help prevent server overload and timeouts when refreshing many charts at once. That’s a useful enhancement, especially for large dashboards, but it’s not strictly necessary for fixing the infinite loop itself.

Removing lastRefreshTime from the Tab.jsx effect dependencies is risky unless you’re sure it won’t break legitimate refresh scenarios. The merged fix avoids this by tracking handled refreshes with a ref, so it’s safer and more robust.

If you want to propose staggered forced refreshes as an enhancement, it’s worth opening a PR and discussing it with the team. For the infinite loop bug, the merged solution is the right fix.

To reply, just mention @dosu.

---

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