Catch and handle "The result of this StaticQuery could not be fetched"

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

When an outdated component attempts to fetch stale static query data from the server, the entire site crashes.

While this issue involves the same error message as #26563, I don’t understand what @wardpeet and @sidharthachatterjee have been tasked with solving in that issue. I am reporting a specific reproducible crash.

Gatsby should be able to tolerate a component fetching a static query data JSON file that no longer exists on the server.

Reproduction Link

N/A. This is very hard to reproduce minimally.

Steps to Reproduce

This set of steps will dependably crash any site in Chrome or Edge:

1. Implement a component that implements useStaticQuery.
2. Deploy to Gatsby Cloud.
3. Open the site in a browser, wait for it to finish loading, then close the tab.
4. Make a small edit to the static query, like switching the order of two fields.
5. Deploy to Gatsby Cloud.
6. Reopen the tab.

Expected Result

The page opens, possibly after a refresh.

Actual Result

The site crashes:

1. The old chunk is reloaded from the disk cache (due to cache-control: public, max-age=31536000, immutable).
2. The old chunk tries to reload its static query data JSON file from the server (due to cache-control: public, max-age=0, must-revalidate).
3. The server responds with a 404.
4. The component throws Uncaught Error: The result of this StaticQuery could not be fetched.
5. The site crashes.

One possible solution would be similar to #33844, and would probably involve refreshing the page. An ideal version of this solution would protect against a refresh loop, too.

Environment

Gatsby Cloud. This doesn’t reproduce using gtsb.io or gatsby serve, since these don’t use Gatsby’s recommended caching headers. This issue only occurs when caching chunks.

[aaronadamsCA]

Our traffic is very low right now due to post-holiday lull, but I merged #34225 a few days back and I haven’t seen a single error with this message since. I’m gonna call this resolved, and I’ll reopen if needed.

Thank you!

[aaronadamsCA]

Interestingly, reopening a closed Edge/Chrome tab seems to be the easiest way to reproduce this. It appears to reliably push the browser cache into an unexpected state.

I want to stress that reopening an Edge/Chrome tab is not the only way to trigger this bug. It’s arrived in our logs from iOS Safari, and I’ve also experienced it when waking a sleeping tab on Android. But this unique (possibly buggy) Chromium cache behaviour is definitely making reproduction easier.

I managed to get a partial DevTools capture of a crash; unfortunately even with --auto-open-devtools-for-tabs, Edge doesn’t capture the very beginning, but I think I’ve got a good picture.

The most interesting detail (assuming DevTools isn’t lying!) is that the trigger appears to be a mismatch between the webpack-runtime-[hash].js Gatsby asks for vs. the one it actually gets.

You can see the mismatch here:

The browser downloads a page that asks for new code, but then for whatever reason it executes old code anyway.

Even if this is a browser bug - even if every StaticQuery bug ever captured turns out to be caused by various browser bugs - I still think Gatsby needs an error boundary in core that will catch this error and refresh the page. I’m going to try building an error boundary like that tomorrow, to at least try to make our own sites immune to this issue.

I’ll continue to share my findings.