rudra1337-dev commented on issue #41266:
URL: https://github.com/apache/superset/issues/41266#issuecomment-5032531417
I spent some time digging into this and prototyped a possible fix — wanted to
check the approach with maintainers before turning it into a formal PR.
Worth noting up front: this addresses the missing recovery/UX path described
here — it's not a fix for every possible trigger of a chunk load failure
(e.g.
it won't resolve a genuinely misconfigured Node build, or make a server stop
returning 503s under load — see @Wetbikeboy2500's comment above). What it
does
address is what happens *after* a chunk fails to load, regardless of why.
**Root cause**
The existing `ErrorBoundary` (`src/components/ErrorBoundary/index.tsx`)
catches
every error uniformly and shows a generic "Unexpected error" alert — there's
no
special handling for `ChunkLoadError`, so a stale or missing lazy-loaded
chunk
gets the same dead-end treatment as any other bug, with zero recovery path.
This matches what's noted in the linked #39219 as well: no built-in retry
logic
exists for failed chunk loads.
**Repro (100% reproducible locally, no need for an actual redeploy)**
1. Run the frontend dev server, load the app, navigate once so some chunks
load.
2. In Chrome DevTools → Network, right-click a lazy-loaded chunk (e.g.
`SqlLab.[hash].chunk.js`) → "Block request URL".
3. Navigate to the route that needs that chunk (e.g. SQL Lab).
4. Console shows `Uncaught ChunkLoadError: Loading chunk SqlLab failed.`,
and the
UI falls back to the ErrorBoundary's generic alert.
This also matches @Wetbikeboy2500's report that navigating away and back
doesn't
recover — currently nothing retries or recovers automatically, and the error
persists even after the underlying resource becomes reachable again.
**Prototyped approach**
Detect `ChunkLoadError` specifically in `componentDidCatch` and trigger a
one-time `window.location.reload()`, guarded by a short `sessionStorage`
timestamp window so a persistently broken chunk doesn't cause an infinite
reload loop — it falls through to the normal error UI after one attempt
instead of retrying forever.
- **Stale-chunk case** (redeploy happened): reload fetches a fresh
`index.html` pointing at the new chunk hash → recovers silently, user never
sees an error.
- **Persistently broken case** (e.g. sustained 503s, network genuinely down):
one reload attempt, then falls back to the existing error alert instead of
an infinite loop — strictly better than today's no-recovery-at-all
behavior, though it doesn't address the underlying cause of sustained 503s.
**Verified locally:**
- Added test coverage in `ErrorBoundary.test.tsx` for: reload-on-chunk-error,
guard-window preventing a second reload, and `onError` still firing before
reload. All 6 tests pass (3 existing + 3 new).
- `npm run lint` — 0 errors
- `npm run type` — clean
- Manually verified both outcomes: (a) persistently blocked chunk → reload
once, then shows the normal error alert instead of looping forever;
(b) chunk becomes available again after the reload → target page loads
successfully with no error shown to the user at all.
This is a prototype, not a polished PR yet — if this direction seems
reasonable, I'll clean it up, open the PR, and add whatever else you'd want
(more test cases, a different guard window, etc.). If it's not the right
direction, happy to hear why before I put more time into it.
--
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]
