Catch and handle ChunkLoadError · gatsbyjs/gatsby#33844

2021-11-03T17:24:00.000Z

### Preliminary Checks - [X] This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues - [X] This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions ### Description We continue to see unhandled `ChunkLoadError` reports in our Sentry logs, as previously tracked in #18866. ### Reproduction Link N/A ### Steps to Reproduce N/A ### Expected Result Gatsby should catch `ChunkLoadError` and then examine and handle the error. ### Actual Result I continue to see `ChunkLoadError` unhandled exceptions in our Sentry logs. @KyleAMathews added a workaround in #33032, where the page reloads on `ChunkLoadError`, but issues remain: - The error still bubbles to the app, and then to our Sentry logs. - If a chunk really was missing, for example due to a Webpack or CDN issue, the application would enter into an infinite loop. In a worst-case scenario this could DDoS an already-broken server or host. - This can be reproduced by using DevTools to block requests for a single `.js` chunk and refreshing. The application starts aggressively refreshing. I think the current workaround was written the way it is because @KyleAMathews believed this error is uncatchable: https://github.com/gatsbyjs/gatsby/issues/18866#issuecomment-845561804 But I'm reasonably confident that I wouldn't be seeing this in my Sentry logs if that were true. If our error boundary can catch it, certainly a Gatsby error boundary could do the same. With some guidance I'd be happy to take a shot at a PR. Specifically I'd love any ideas on avoiding the refresh loop - I think it would be better to crash on a second consecutive error - and on whether it would be possible to write tests that cover this. ### Environment ```shell Gatsby latest. ``` ### Config Flags _No response_

(9 comments) (11 reactions) (0 assignees)JavaScript (55,950 stars) (10,198 forks)batch import

help wantedstatus: confirmedtopic: webpack/babeltype: bug

Description

Preliminary Checks

This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

We continue to see unhandled ChunkLoadError reports in our Sentry logs, as previously tracked in #18866.

Reproduction Link

N/A

Steps to Reproduce

N/A

Expected Result

Gatsby should catch ChunkLoadError and then examine and handle the error.

Actual Result

I continue to see ChunkLoadError unhandled exceptions in our Sentry logs.

@KyleAMathews added a workaround in #33032, where the page reloads on ChunkLoadError, but issues remain:

The error still bubbles to the app, and then to our Sentry logs.
If a chunk really was missing, for example due to a Webpack or CDN issue, the application would enter into an infinite loop. In a worst-case scenario this could DDoS an already-broken server or host.
- This can be reproduced by using DevTools to block requests for a single .js chunk and refreshing. The application starts aggressively refreshing.

I think the current workaround was written the way it is because @KyleAMathews believed this error is uncatchable: https://github.com/gatsbyjs/gatsby/issues/18866#issuecomment-845561804

But I'm reasonably confident that I wouldn't be seeing this in my Sentry logs if that were true. If our error boundary can catch it, certainly a Gatsby error boundary could do the same.

With some guidance I'd be happy to take a shot at a PR. Specifically I'd love any ideas on avoiding the refresh loop - I think it would be better to crash on a second consecutive error - and on whether it would be possible to write tests that cover this.

Environment

Gatsby latest.

Config Flags

No response

Contributor guide

Tech stack: javascriptreact
Domain: frontend
Issue type: bug
Difficulty: 3
Estimated time: half day
Activity status: fresh
Clarity: mostly clear
Prerequisites: Understanding of Gatsby error boundariesFamiliarity with Webpack chunk loading
Newbie friendliness: 60
Research direction: Investigate the current workaround in PR #33032 which reloads the page on ChunkLoadError. The issue is to catch the error in an error boundary before it bubbles to Sentry, and to implement a rate limited retry or crash on consecutive errors to avoid infinite loops. Look at Gatsby's error boundary implementation and consider adding a counter or timestamp check. Also consider if tests can be written for this case.