Error / page resources for / not found. Not rendering React

[antoinerousseau]

Description

I'm having multiple Bugsnag reports from Safari and Mobile Safari (various versions and browsers) of this error in .cache/production-app.js in publicLoader.loadPage:

Steps to reproduce

I don't see this Error in my macOS Safari. Website is https://lebikini.com

Expected result

No error

Actual result

An error

Environment

  System:
    OS: macOS 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.15.3 - ~/.nvm/versions/node/v10.15.3/bin/node
    Yarn: 1.19.0 - /usr/local/bin/yarn
    npm: 6.12.0 - ~/.nvm/versions/node/v10.15.3/bin/npm
  Languages:
    Python: 2.7.16 - /usr/local/bin/python
  Browsers:
    Chrome: 78.0.3904.97
    Firefox: 70.0
    Safari: 13.0.3
  npmPackages:
    gatsby: ^2.17.13 => 2.17.13
    gatsby-image: ^2.2.32 => 2.2.32
    gatsby-plugin-google-analytics: ^2.1.26 => 2.1.26
    gatsby-plugin-manifest: ^2.2.27 => 2.2.27
    gatsby-plugin-netlify: ^2.1.24 => 2.1.24
    gatsby-plugin-react-helmet: ^3.1.14 => 3.1.14
    gatsby-plugin-sharp: ^2.2.38 => 2.2.38
    gatsby-plugin-styled-components: ^3.1.12 => 3.1.12
    gatsby-plugin-typescript: ^2.1.17 => 2.1.17
    gatsby-source-filesystem: ^2.1.36 => 2.1.36
    gatsby-transformer-sharp: ^2.3.4 => 2.3.4

Related: #15080

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[wardpeet]

@antoinerousseau would it help if we provide a better stacktrace? Like maybe it was 404 or maybe page-data was invalid. At the moment you don't really see a difference.

What do you think the best way moving forward could be? Did you try it on mobile safari/safari yourself?

[antoinerousseau]

@wardpeet thanks for looking into this.
I tried with Safari desktop and I couldn't reproduce. I don't own an iPhone.
I'm not sure how to proceed, since it happens only sometimes and randomly, but a better stacktrace can't hurt anyway.
Note that it only happened 124 times, with 85% Mobile Safari, 10% Safari and 5% Chrome Mobile iOS. Various versions.
Also the URL is not always /. I can give you access to the Bugsnag account if you want.

[baba43]

I've had the same bug report today. Just to let you know that you're not alone.

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜

[Undistraction]

Seeing the same thing.

• It's reasonably often (we are seeing it daily).
• Almost all Mobile Safari or Safari.
• Almost always /, but very rarely other pages.
• Sentry gives the same stacktrace as Bugsnag with the following breadcrumbs:

[burtyish]

Same here. For a page other than /index.

Device
Brand | Huawei
Family | DRA-LX5

OS
Name | Android
Version | 8.1.0

Browser
name | Chrome Mobile WebView
version | 70.0.3538

SDK
Name | sentry.javascript.browser
Version | 5.12.1

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[Undistraction]

Still an issue.

[vedantroy]

I'm also getting this issue. gatsby develop works fine, but gatsby build causes the application to break with "Error: page resources for / not found. Not rendering React." at runtime even though the build itself suceeds.

Could this be caused by the fact that I am using Typescript?

I have tried running gatsby clean

Update/Possible Solution: For me the error was caused because I only had a ".env.development" file and not a ".env.production" file. I don't know why this gave such an ambiguous/confusing error and prevented React from rendering though. I feel like the expected behavior would be the same behavior as what happens when I run gatsby develop. When I run gatsby develop and don't have a .env.development file, React still renders but my app crashes because it is missing the important values.

[Kanuny]

I've got same issue. My app hosted on aws and uses cloudfront. I have a policy to redirect all not-existed urls to 404.html page with status 200. This looks strange, but it's really important for one of our features. So in case I type something like my-test-site.com/some-not-existed-page window.pagePath would be /404.html which is correct, but publicLoader.loadPage somewhy tries to load not a 404.html page content, but /my-test-site.com/some-not-existed-page. In fact it uses window.location.pathname but not window.pagePath

[JustFly1984]

I got same error message in Sentry today: not found. Not rendering React

[DennisOosterling]

I was encountering this issue as well. For me it was reproducible when using named imports for your own components in the pages/index.js file.

Example
import Layout from "../components/Layout"; ✅
import { Layout } from "../components"; 🚫

components/index.js would look like this:

import Layout from "./Layout"

export {
  Layout
};

This was with MacOS catelina & chrome Version 80.0.3987.149.
"gatsby": "^2.20.13",

Important to note is that I'm using the expo gatsby variant.

[stuntbaboon]

I also had this issue when running a clean gatsby build and the root cause was a resolution in my package.json for an acorn package vulnerability (see https://snyk.io/vuln/npm:acorn):

"resolutions": {
   "acorn": "^7.1.1"
}

Removing this resolution solved the issue for me.

Output from gatsby info:

  System:
    OS: macOS 10.15.4
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.10.0 - /usr/local/bin/node
    Yarn: 1.22.4 - ~/.yarn/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
  Languages:
    Python: 2.7.17 - /usr/local/bin/python
  Browsers:
    Chrome: 81.0.4044.92
    Safari: 13.1
  npmPackages:
    gatsby: 2.20.20 => 2.20.20 
    gatsby-plugin-material-ui: 2.1.6 => 2.1.6 
    gatsby-source-graphql: 2.4.0 => 2.4.0 

[antoinerousseau]

Still happens a lot (4,500+ times over the last week):

Stacktrace on Mobile Safari:

.cache/production-app.js:128:12

126  publicLoader.loadPage(browserLoc.pathname).then(page => {
127    if (!page || page.status === PageResourceStatus.Error) {
128      throw new Error(
129        `page resources for ${browserLoc.pathname} not found. Not rendering React`
130      )
131    }

Stacktrace on Chrome Mobile:

/app-ac76ae7860adc4ef4414.js:1:179819

Breadcrumbs:

Time	Type	Error	Infos
4ms before	REQUEST	XMLHttpRequest error	GET /page-data/app-data.json
5ms before	REQUEST	XMLHttpRequest error	GET /page-data/index/page-data.json
6ms before	REQUEST	XMLHttpRequest error	GET /page-data/app-data.json
7ms before	REQUEST	XMLHttpRequest error	GET /page-data/index/page-data.json
10ms before	REQUEST	XMLHttpRequest error	GET /page-data/app-data.json
10ms before	REQUEST	XMLHttpRequest error	GET /page-data/index/page-data.json

Most of them happen on Mobile Safari and Chrome Mobile:

Gatsby version: 2.20.13

[akilicarslan]

Check this solution.
#11461 (comment)

[antoinerousseau]

I don't use gatsby-plugin-offline so there are no service workers.

[Undistraction]

@wardpeet Thanks. That's really good to hear.

[holm]

Awesome

[alana314]

I'm seeing this error too but only in IE 11. I know. I have to support IE 11.

[alessbell]

Also seeing this error only in IE 11

[Auspicus]

I had some speculation on what could be causing it since it seems a bit intermittent and dependent on network conditions. With these errors it should be a bit easier to diagnose. Could this be caused by a change in the static query file hash which would make the previous version of the file unreachable at the edge until the reference to the file is updated in the page that is using it? @wardpeet

Hypothetical reproduction?:

• static query asks for site metadata (eg. title)
• between one build and another the static query results change (eg. a change to the title)
• now the static query results will live under a new id (eg. /sq/d/123.json now lives at /sq/d/345.json) [EDIT: this will only happen if you change the actual graphql query text]
• pages previously rendered which referenced this file will refer to an old version of the static query (eg. /sq/d/123.json)
• this json no longer exists so when it is loaded and parsed as json this throws an error because the file is not json

If I have time to run through these steps properly I will but this is my speculation into whats happening here. Good to know I'm not the only one seeing this! We see it mainly in Safari and iPhone but Mac and Windows also occasionally pop up. Not sure if it makes sense to make this an issue specific to a particular device or browser yet though.

EDIT: maybe I'm wrong here. Take this with a grain of salt. Don't want to send people on wild goose chase :)
EDIT: eyeing the dirty queries section of gatsby core to see if I can glean some sort of consistent way to reproduce this

gatsby/packages/gatsby/src/redux/reducers/queries.ts

Lines 51 to 240 in 478cf68

	/**
	* Tracks query dirtiness. Dirty queries are queries that:
	*
	* - depend on nodes or node collections (via `actions.createPageDependency`) that have changed.
	* - have been recently extracted (or their query text has changed)
	* - belong to newly created pages (or pages with modified context)
	*
	* Dirty queries must be re-ran.
	*/
	export function queriesReducer(
	state: IGatsbyState["queries"] = initialState(),
	action: ActionsUnion
	): IGatsbyState["queries"] {
	switch (action.type) {
	case `DELETE_CACHE`:
	return initialState()
	case `CREATE_PAGE`: {
	const { path, componentPath } = action.payload
	let query = state.trackedQueries.get(path)
	if (!query || action.contextModified) {
	query = registerQuery(state, path)
	query.dirty = setFlag(
	query.dirty,
	action.contextModified ? FLAG_DIRTY_PAGE_CONTEXT : FLAG_DIRTY_NEW_PAGE
	)
	state = trackDirtyQuery(state, path)
	}
	registerComponent(state, componentPath).pages.add(path)
	state.deletedQueries.delete(path)
	return state
	}
	case `DELETE_PAGE`: {
	// Don't actually remove the page query from trackedQueries, just mark it as "deleted". Why?
	// We promote a technique of a consecutive deletePage/createPage calls in onCreatePage hook,
	// see https://www.gatsbyjs.com/docs/creating-and-modifying-pages/#pass-context-to-pages
	// If we remove a query and then re-add, it will be marked as dirty.
	// This is OK for cold cache but with warm cache we will re-run all of those queries (unnecessarily).
	// We will reconcile the state after createPages API call and actually delete those queries.
	state.deletedQueries.add(action.payload.path)
	return state
	}
	case `DELETED_STALE_PAGE_DATA_FILES`: {
	// this action is a hack/hot fix
	// it should be removed/reverted when we start persisting pages state
	for (const queryId of action.payload.pagePathsToClear) {
	for (const component of state.trackedComponents.values()) {
	component.pages.delete(queryId)
	}
	state = clearNodeDependencies(state, queryId)
	state = clearConnectionDependencies(state, queryId)
	state.trackedQueries.delete(queryId)
	}
	return state
	}
	case `API_FINISHED`: {
	if (action.payload.apiName !== `createPages`) {
	return state
	}
	for (const queryId of state.deletedQueries) {
	for (const component of state.trackedComponents.values()) {
	component.pages.delete(queryId)
	}
	state = clearNodeDependencies(state, queryId)
	state = clearConnectionDependencies(state, queryId)
	state.trackedQueries.delete(queryId)
	}
	state.deletedQueries.clear()
	return state
	}
	case `QUERY_EXTRACTED`: {
	// Note: this action is called even in case of
	// extraction error or missing query (with query === ``)
	// TODO: use hash instead of a query text
	const { componentPath, query } = action.payload
	const component = registerComponent(state, componentPath)
	if (hasFlag(component.errors, FLAG_ERROR_EXTRACTION)) {
	return state
	}
	if (component.query !== query) {
	// Invalidate all pages associated with a component when query text changes
	for (const queryId of component.pages) {
	const query = state.trackedQueries.get(queryId)
	if (query) {
	query.dirty = setFlag(query.dirty, FLAG_DIRTY_TEXT)
	state = trackDirtyQuery(state, queryId)
	}
	}
	component.query = query
	}
	return state
	}
	case `QUERY_EXTRACTION_GRAPHQL_ERROR`:
	case `QUERY_EXTRACTION_BABEL_ERROR`:
	case `QUERY_EXTRACTION_BABEL_SUCCESS`: {
	const { componentPath } = action.payload
	const component = registerComponent(state, componentPath)
	const set = action.type !== `QUERY_EXTRACTION_BABEL_SUCCESS`
	component.errors = setFlag(component.errors, FLAG_ERROR_EXTRACTION, set)
	return state
	}
	case `REPLACE_STATIC_QUERY`: {
	// Only called when static query text has changed, so no need to compare
	// TODO: unify the behavior?
	const query = registerQuery(state, action.payload.id)
	query.dirty = setFlag(query.dirty, FLAG_DIRTY_TEXT)
	// static queries are not on demand, so skipping tracking which
	// queries were marked dirty recently
	// state = trackDirtyQuery(state, action.payload.id)
	state.deletedQueries.delete(action.payload.id)
	return state
	}
	case `REMOVE_STATIC_QUERY`: {
	state.deletedQueries.add(action.payload)
	return state
	}
	case `CREATE_COMPONENT_DEPENDENCY`: {
	const { path: queryId, nodeId, connection } = action.payload
	if (nodeId) {
	state = addNodeDependency(state, queryId, nodeId)
	}
	if (connection) {
	state = addConnectionDependency(state, queryId, connection)
	}
	return state
	}
	case `QUERY_START`: {
	// Reset data dependencies as they will be updated when running the query
	const { path } = action.payload
	state = clearNodeDependencies(state, path)
	state = clearConnectionDependencies(state, path)
	const query = state.trackedQueries.get(path)
	if (query) {
	query.running = setFlag(query.running, FLAG_RUNNING_INFLIGHT)
	}
	return state
	}
	case `CREATE_NODE`:
	case `DELETE_NODE`: {
	const node = action.payload
	if (!node) {
	return state
	}
	const queriesByNode = state.byNode.get(node.id) ?? []
	const queriesByConnection =
	state.byConnection.get(node.internal.type) ?? []
	for (const queryId of queriesByNode) {
	const query = state.trackedQueries.get(queryId)
	if (query) {
	query.dirty = setFlag(query.dirty, FLAG_DIRTY_DATA)
	state = trackDirtyQuery(state, queryId)
	}
	}
	for (const queryId of queriesByConnection) {
	const query = state.trackedQueries.get(queryId)
	if (query) {
	query.dirty = setFlag(query.dirty, FLAG_DIRTY_DATA)
	state = trackDirtyQuery(state, queryId)
	}
	}
	return state
	}
	case `PAGE_QUERY_RUN`: {
	const { path } = action.payload
	const query = registerQuery(state, path)
	query.dirty = 0
	query.running = 0 // TODO: also
	return state
	}
	case `SET_PROGRAM_STATUS`: {
	if (action.payload === `BOOTSTRAP_FINISHED`) {
	// Reset the running state (as it could've been persisted)
	for (const [, query] of state.trackedQueries) {
	query.running = 0
	}
	// Reset list of dirty queries (this is used only to notify runtime and it could've been persisted)
	state.dirtyQueriesListToEmitViaWebsocket = []
	}
	return state
	}
	case `QUERY_CLEAR_DIRTY_QUERIES_LIST_TO_EMIT_VIA_WEBSOCKET`: {
	state.dirtyQueriesListToEmitViaWebsocket = []
	return state
	}
	default:
	return state
	}
	}

EDIT: can confirm that changing a static query inside a file will change the id which would definitely produce this issue for stale pages. Haven't tested yet whether or not changing the data the static query depends on will also update the ID, most likely it will.
EDIT: changes to data which is being queried in a static query (at least data stored in siteMetadata) will not cause the query id to change, existing references will continue to work

[kellymilligan]

I'm seeing this in IE11 only as well:

Happpening on both my locally built (gatsby build && gatsby serve) and on a hosted dev URL.

Originally I was just getting the page resources for / not found. Not rendering React error, but having updated gatsby to latest which includes @wardpeet 's #29970 merge, getting an additional Unhandled promise rejection TypeError: Invalid calling object error:

In case it's useful:

[Auspicus]

I am able to reproduce this consistently (on Gatsby 3.0.1) with a combination of gatsby clean and gatsby build whilst navigating a site and making a small change to a static query.

Here's a repo I created by making 2 small changes to the gatsby-starter-default repo.

If you follow the steps in the README.md you will be able to reproduce the error yourself in your browser (this particular reproduction is not dependent on you using any specific browser). This reproduction is probably not indicative of the entire problem. This is just an easy way to reproduce it. I will also include a video here reproducing the error for those who don't have an easy setup for their local environment. https://www.youtube.com/watch?v=mGpB0xnZLn4

I'm not sure what the solution here is and it's not the worst UX in the world (clicking a link doesn't do anything) because it just requires a hard refresh to fetch new page-data so that the page can be loaded. This might be causing worse errors in other cases. The underlying issue is really just that page-data can sometimes be stale and all the obscure cases where that might happen need to be handled. @wardpeet

[pfarnach]

I was seeing this error too, and in my case following the steps in https://www.gatsbyjs.com/docs/caching/ seems to have resolved the issue. I suspect that app-data.json and/or page-data.json were stale after deploys which was causing issues. Will update here if the issue resurfaces.

[JustFly1984]

@Auspicus @pfarnach I've used github actions for deploy to S3. Had not setup any additional caching.

[aaronadamsCA]

I don't know if this odd detail helps at all, but:

• We first noted this error on January 23, sent by @sentry/gatsby v5.29.2.
• We upgraded @sentry/gatsby on February 3, and multiple times since.
• We are still seeing this error as recently as two days ago... sent by @sentry/gatsby v5.29.2. 🤔

Some strange iPhone out there has a VERY old version of our site cached, and keeps requesting it to this day.

[Auspicus]

@aaronadamsCA So you're seeing the old version of sentry continuing to send this error long after updating the package?

That might be a very valuable insight into real world reproduction.

[aaronadamsCA]

That's right. Some details:

• We were on Netlify CDN (we just switched to Gatsby Cloud this week) with gatsby-plugin-netlify, no custom settings.
• We can probably rule out offline mode. We tried gatsby-plugin-offline for a week last August, had too many problems, and switched to gatsby-plugin-remove-serviceworker; offline mode never co-existed with the version of @sentry/gatsby we see still sending errors.

I'm guessing the browser indefinitely caches an old HTML document and broken app-{hash}.js bundle; and every time the site is reopened on that device, the document and broken script run from the cache.

So I feel like maybe this issue divides cleanly in two:

1. Real app errors were being hidden, which should now hopefully be resolved by feat(gatsby): improve error messages at runtime #29970.
2. Something's up with caching in Chrome and Safari, Firefox unaffected, that can lead to indefinite app caching.

If 2 is caused by some specific variety of 1, then hopefully with #29970 someone's logs will start to provide new insights soon.

[KyleAMathews]

@aaronadamsCA very helpful info/greakdown.

Can you/others provide some sense of what % of devices are sending these errors? Raw number of devices? Which browsers/versions?

[Auspicus]

@KyleAMathews We're getting around 10 - 15 users per hour (out of ~2,500 per hour) reporting JSON Parse error: Unexpected EOF during a session in Sentry. It seems to be more common during hours where content might be changing or code changes might be getting deployed.

[wardpeet]

@Auspicus the bug you're talking about is in par with #18866.

I'm glad that logging helps out here ^^

For the IE11 bugs people are seeing, can we get a little bit more information out there? What code path breaks? Any custom node-module that's used that causes it?

Thank you!

[aaronadamsCA]

Can you/others provide some sense of what % of devices are sending these errors? Raw number of devices? Which browsers/versions?

@KyleAMathews Unfortunately my Sentry logs don't go very far back. At this point I'm down to about 10 "users" in the last 30 days with this error, but I'm guessing I can attribute all of them to one stubborn device still sending the aforementioned data. So I may have resolved my underlying issue, whether by fixing a bug or switching to Gatsby Cloud hosting. 🤷‍♂️

I've specifically seen this from Chrome on Windows, and Safari on iOS and macOS. Never from Firefox, as far as I know.

[nikitaeverywhere]

I've also encountered this problem today: page resources for / not found. It couldn't find /page-data/index/page-data.json. Initially all was working normally, then not working at all (including not building on Gatsby Cloud), then working only locally, then I managed to make it working normally again.

I think the problem is in incremental builds, including incremental build on Gatsby Cloud. What I did to come to this conclusion:

1. I encountered this problem - observed an error on the deployed website on Gatsby Cloud. Locally it worked. But when deployed, the page was flashing for a second and disappearing at all (weird).
2. A few dummy pushes to Gatsby Cloud didn't do anything.
3. Now I tried using npm run build locally, and got the same error when static serving the local directory.
4. By tossing some local files and deleting /public directory and deleting .cache, I managed the locally served version to work.
5. However I was surprised that once I deployed things to Gatsby Cloud it wasn't building, still.
6. Spent half an hour trying things and cutting my application to a bare minimum - it didn't work.
7. Finally, I noticed that sourcemaps are deployed to production by default (what a weird decision, Gatsby team). I decided to turn them off by doing this: effectively, creating a new gatsby-node.js file.
8. When this change got deployed, it seems like Gatsby purged its cloud cache and has built my website normally.

Takeaways:

I suspect incremental builds are wrong. How come you can easily break production by just deploying things that work locally? Besides that, big thanks to a Gatsby team for building the thing - has strange parts and design decisions but at the end of the day works.

P.S. Why it has reproduced for me? My guess - I was playing around with index.tsx file (index directory), trying to move it to /src/pages/index/index.tsx. I wasn't lucky and I moved it back. Then I was renaming more files (like styles, 404 page etc). I *suppose* somewhere here Gatsby's cache could get confused: it was not building /public/page-data/index/page-data.json file. And consecutively every next incremental build has got confused too.

[martinljones]

@ZitRos Thanks for the source map tip - I have a bare bones project as well hosted on IIS. I just deployed a build and confirmed source maps were gone from my wwwroot by hopping on the box and i'm still seeing the same issue - figured I'd call out no fix for me.

[nikitaeverywhere]

@martinljones to clarify, there's no relation between sourcemaps and the described issue, I noted that perhaps it's sourcemaps change which has triggered a cache wipe on Gatsby Cloud, which I guess can also be achieved with this button (which I didn't try):

Locally, gatsby clean and deleting .cache directory solved it for me.

[martinljones]

@ZitRos ah! thanks for the clarification.

@martinljones to clarify, there's no relation between sourcemaps and the described issue, I noted that perhaps it's sourcemaps change which has triggered a cache wipe on Gatsby Cloud, which I guess can also be achieved with this button (which I didn't try):

[aaronadamsCA]

the page was flashing for a second and disappearing at all (weird).

@ZitRos, you may want to look back at that deployment and check for a client-side JavaScript error on that page. What you've described is how Gatsby behaves when a page builds correctly on the server side, but then throws an unhandled exception on the client side.

[kdichev]

I have been trying to update our gatsby project to v2.18.17+ and now eventually to v3. The initial tries a few months ago were unsuccessful because of the error described in this issue.

We have now updated to v3 and did not initially see the issue until our test team flagged a page with the error (ouch I thought I need to revert my updates) but this time there was another error message along side and it pointed to an undefined call.

I digged up thru the stack trace and was pointed to a react component in our codebase that basically imported itself, after removing this code block the issue went away. Hope this helps!

[LekoArts]

The initial issue (opened in 2019!) diverged quite a lot to a discussion of seemingly different issues (but the same error message on the surface). Some people had errors in their code, some needed correct caching set up (https://www.gatsbyjs.com/docs/caching/) and some might be an issue with IE11. I'll mark this issue here as fixed as the error now gives you the full details of what's happening and we'd very much appreciate if you open new bug reports with minimal reproductions so that we can focus on each issue on its own. A big issue like this here gets difficult to track once multiple people comments with different things. Thanks!

[redblue9771]

I have the same problem, and I can access it normally by using shift+cmd+R. https://redblue.fun/

[LekoArts]

Please see: #19618 (comment)