Catch and handle ChunkLoadError

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