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

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! 💪💜

@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?

@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.

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

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! 💪💜

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! 💪💜

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:
  

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

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! 💪💜

Still an issue.

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.

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

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

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.

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 

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

Check this solution.
https://github.com/gatsbyjs/gatsby/issues/11461#issuecomment-459732145

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

Is there any progress? I'm having an issue, and I have plugin offline, and I can't disable the plugin to test if errors goes off.

I don't think this has anything to do with the offline plugin. We are seeing plenty of these errors and have never used it.

To reproduce:

• Go to [example no longer needed, see below], note error in console and non-functional React.
• Navigate to the home page with logo in top left.
• Navigate back to the original page by clicking "Research" in the header. Page now works and panels are collapsible.

How do I debug this? There are no network requests which 404 or anything, so I don't understand what's happening. Local versions are as follows, but builds happen on Netlify:

  System:
    OS: macOS 10.15.3
    CPU: (4) x64 Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.16.1 - ~/.nvm/versions/node/v12.16.1/bin/node
    Yarn: 1.22.4 - ~/.yarn/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v12.16.1/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 81.0.4044.122
    Firefox: 75.0
    Safari: 13.0.5
  npmPackages:
    gatsby: 2.21.1 => 2.21.1
    gatsby-image: 2.4.0 => 2.4.0
    gatsby-plugin-graphql-loader: 1.0.2 => 1.0.2
    gatsby-plugin-module-resolver: 1.0.3 => 1.0.3
    gatsby-plugin-page-creator: 2.3.0 => 2.3.0
    gatsby-plugin-react-helmet: 3.3.0 => 3.3.0
    gatsby-plugin-sharp: 2.6.0 => 2.6.0
    gatsby-plugin-typescript: 2.4.0 => 2.4.0
    gatsby-source-contentful: 2.3.1 => 2.3.1
    gatsby-transformer-remark: 2.8.0 => 2.8.0
    gatsby-transformer-sharp: 2.5.0 => 2.5.0

In our case we had a page as the default export, then had a named export in the page file as well. As soon as anything referenced the named export from outside of the page file, it got very confused.

Fix was to remove all exports from the pages except the default actual page component export.

@thekevinbrown Was the error you were seeing intermittent? Or did it happen every time?

@Undistraction every time you started or refreshed on the page with the problem. If you started on a different page, or navigated off of the page to a working one, then back, it was fine. So basically initial hydration fails in this case, while if you can get the user onto a different page where hydration works, then the downloading and showing of the broken page works.

Would definitely have been better as a clear build error instead of an obscure runtime error if that's possible.

@thekevinbrown so I think your issue is unrelated to this this issue (which is an intermittent error that nobody has been able to reliably reproduce), so I think although you are seeing the same error, the cause is different (and thankfully you've easily fixed it).

Encountered this error in our prod site and upgrading to the latest Gatsby version (release just 2 days ago) fixed the bug for Safari

Upgraded to the latest Gatsby version. Problem still occures

I have never experienced this before. Suddenly it happens every time. Only in production 😢
This happened after an update 20 hours ago. We quite regularly update dependencies.
So basically the project is down and I have no idea how to get it working again.

I tried reverting updates to what they were 20 hours ago. Did not help.
Reverting to 8 days ago did not help either.

Here is the project with newish updates: https://vermehrungch-4utm3ymcd.now.sh/Vermehrung/
And here the last working one from 8 days ago: https://vermehrungch-9l709pu84.now.sh/Vermehrung/

Reverting gatsby dependencies to what they were 9 Days ago got a new build to work again 😆

Will now try to isolate what gatsby dependency causes it.

O.k., in our case:

• definitely gatsby itself is the cause
• versions until 2.20.36 work
• v2.21.2 and v2.21.3 have above error (I had tested v2.21.17 earlier, same error)
• v2.21.0 has different error:
  idb-keyval-iife.min.js:1 Uncaught (in promise) DOMException: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing. at https://vermehrungch.gabriel-software.now.sh/idb-keyval-iife.min.js:1:353 at new Promise (<anonymous>) at https://vermehrungch.gabriel-software.now.sh/idb-keyval-iife.min.js:1:323 at async Object.handle (https://vermehrungch.gabriel-software.now.sh/sw.js:162:21)

Update: The error still happens in gatsby v2.21.19

@barbalex could you share your site with us? If it's private send an email to [email protected].

I'm getting this error on your site when I debug it

[].concat(function(e) {
                if (Array.isArray(e)) {
                    for (var t = 0, n = Array(e.length); t < e.length; t++) n[t] = e[t];
                    return n
                }
                return Array.from(e)
            }(Object.keys(it.propTypes)), ["children"]);

Stacktrace:

TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at Module.zJQU (VM54 component---src-pages-vermehrung-js-c3ca1cb1b4686475777d.js:13787)
    at c (webpack-runtime-2b4bd8eda0563b1ea7e6.js:1)

The site is:

• https://vermehrung.ch
• https://github.com/barbalex/vermehrung
• you can even log in using the password sent in mail

The site is in development. So you can even edit data.

We got same error messages in Sentry recurrently:

We are using gatsby version "2.21.22".

I encountered same issue and fixed by downgrading to v2.20.36, which is mentioned above.

O.k., in our case:

• definitely gatsby itself is the cause
• versions until 2.20.36 work
• v2.21.2 and v2.21.3 have above error (I had tested v2.21.17 earlier, same error)

I ran into this again in a different project that had version 2.21.12. This is _really_ bad as it occurs only in production. Please prioritize this bug.

We are seeing this in production on https://www.voteamerica.com/. It happens primarily on Mobile Safari, but we're also seeing it on Android Chrome, desktop Safari, desktop Chrome, and others. We are currently using Gatsby 2.21.40, but we were also seeing the issue on 2.20.12

Got the same issue for the one page that has been deleted recently. https://intergiro.com/legal doesn't show the custom 404 page as it's expected (desktop Chrome, Gatsby 2.20.8). Occurs only in production as well.

In my case, @Kanuny 's comment indirectly solved my issue. I accidentally redirected the page data JSON to a HTML file when publicLoader.loadPage was trying to fetch it. After fixing the redirects, the page data JSON loads properly and all works as usual.

The bug suddenly disappeared again. Looks like it might be linked to cache or something

The error is still happening in the 2.22.12 version on Firefox and Chrome latest versions too.

Please fix it!

Please fix it!

@SoldierCorp please read about what Open Source is and maybe try fixing it yourself.

@antoinerousseau it's also about helping each other, where the ones who need help - ask for it, and the ones who know how - offer it. So I think your comment is out of place.

@andrzejwp yes it's about helping each other, not about posting bossy comments like "please fix it!" with no useful information to actually fix the issue, while notifying 25 people following this issue.

Others have commented with detailed insights about how it affects them, which is needed to make the contributors help them and hopefully fix OSS issues.

@antoinerousseau There is no more useful information related to this one because there is no more information provided by the issue so it just happens, so I wrote that to avoid repeating the same stuff other people are writing because is the same at the end till the latest version.

Is just to let Gatsby know that more people are still experiencing the problem and hasn't been fixed yet.

Sorry if that is bothering you but I am a regular user that is using the framework and for not having time to fix the issue by myself.

In my case, this was only occurring when prefixing paths, since I am attempting to use gatsby-plugin-ipfs (Running gatsby build --prefix-paths && gatsby serve would yield a "Error / page resources for / not found. Not rendering React" for every page).
However, in my index.jsx page I was not running any page queries, but I did have a component that contained a staticQuery, from the useStaticQuery hook.
If I commented out this component and rebuild, then the error would go away.
Interestingly enough, if I then uncommented this component and rebuild again (so the site is back in the initial state), then it would run fine, and not encounter the "Error / page resources for / not found. Not rendering React" error, suggesting that the build cache contains something important?

So my (rough) thoughts for why this could occur are:

• Issues with the index page containing a static query, but not a page query?
• Issues with the order of the build process (since caching can modify the results).
• Potentially an issue with run static queries or Generating image thumbnails in the build process, since these are the only steps that seem to be skipped thanks to the cache.

I accidentally redirected the page data JSON to a HTML file

Similar situation here. Essentially, an nginx location directive regex was also matching /page-data/items/page-data.json when it shouldn't have. Adding a ^ at the beginning of the regexp avoided the unintended match.

We are seeing this in production on https://www.voteamerica.com/. It happens primarily on Mobile Safari, but we're also seeing it on Android Chrome, desktop Safari, desktop Chrome, and others. We are currently using Gatsby 2.21.40, but we were also seeing the issue on 2.20.12

Also facing the same issue.

Hi Gatsby team, hi everyone. Would it be possible to specify the errors returned in loadPage which seems to be the source of the various errors surfaced in this issue?

Ref to the function: https://github.com/gatsbyjs/gatsby/blob/030d927cddbdc64f8d93d409a5ada7442d5e62bf/packages/gatsby/cache-dir/loader.js#L179-L242

It is my understanding that this function tries to load app-data.json, page-data.json and then the JS components themselves, thus being very prone to network issues, server config issues, dev issues, config issues... By specifying the error message it would be easier to fix the underlying problems.

(For reference: the last occurence of this issue on our website was because of a circular import)

I tried again with v2.23.12. Same result: https://vermehrungch-1j64x2olp.vercel.app/Vermehrung

To us it seems absolutely systematic since every version above 2.20.36. On every of five apps built using gatsby. So we have been blocked from updating since.

Which is starting to become a bit of an issue. For instance we are blocked from using any libs using core-js in v3 (https://github.com/gatsbyjs/gatsby/issues/15601). That issue has now been solved - if we _could_ upgrade.

If there is any way I can help with information/tests/whatever, I gladly would.

@barbalex You have the following error in your app:

We should definitely show this error. Feel free to add a PR, I don't have enough bandwidth to do this atm.

It seems that this issue is in our case caused by react-contextmenu when that lib is used server side: https://github.com/vkbansal/react-contextmenu/issues/284, which seems to be triggered during the build process.

@wardpeet

Feel free to add a PR, I don't have enough bandwidth to do this atm

Sorry to say, I don't seem to have enough grey cells for that 😢
Maybe @b4stien does?

The issue is still persists on 2.23.21 version

I haven't got a catch-all solution for this, but I just wanted it to be known that I had this issue this morning for the first time ever.

And I managed to "fix" it.

The site is hosted on AWS via a provider called "Cloudways".

As an initial test, I deployed the site to Netlify - And everything worked just fine.

After digging around a bit, there seemed to be a server-side cache issue using something called "Varnish".

I first tried to "purge" it, and nothing happened - But disabling and re-enabling it worked.

This site has existed just fine for about 18 months in this environment with regular updates, and this was the first time I'd had encountered this issue.

I recently upgraded to:
Gatsby CLI version: 2.12.59

Not sure if this could have had any effect, but it's the only change I can think of - Unless of course there was a change on the hosting side of things.

Hopefully this helps someone out there 🤷

EDIT:

The issue came back within 5 mins when I re-enabled the "varnish" cache.

I've disabled this feature for now.

In our case every page created from /pages folder works but the rest created by createPages fail to rehydrate react.
We are experiencing this issue on both local and CI.

in our case all the pages created with createPages, cos we are using internationalization with /${locale}/ prefix foe every page.

in our case all the pages created with createPages, cos we are using internationalization with /${locale}/ prefix foe every page.

did you find a solution for this? we also have this setup with many locales

@kdichev No I did not found solution. Waiting for gatsby team to fix this on library level.

I am still quite unsure where the issue is, I would happily make a PR for this but would like if we get and find where the underlying issue is?

Hey Guys, I'm facing this Issue on production using IE11.

"gatsby": "^2.23.11"

Also facing a blank(no hydration) result of all pages on IE11.
Page resources for / not found. Not rendering react

Gatsby v2.24.2

EDIT: I reverted to the previous functioning version v2.22.11. ie11 worked in that commit and rightly so it also worked now, albeit only when I kept package-lock.json and npm ci. Somehow I don't believe this is gatsby in the wrong, so I am listing some possible downstream changes that may be relevant:
(working version -> failing build version)
the big ones which are likely candidates for only ie11 failures:
@babel/core 7.10.0 -> 7.10.5
@core/js 2.6.11 -> 3.6.5
gatsby-legacy-polyfills new dep 0.0.2

other less likely:
@graphql-tools/schema new dep 6.0.14
@graphql-tools/utils new dep 6.0.14
and then my patience of sifting through all red->all green in vscode diff tool ran out

Other things of note: I reproduced the error with gatsby build && gatsby serve -H 0.0.0.0, so that rules out any server environment side stuff.

EDIT 2: The build output of the fauly v2.24.2 build first reported in my post went from 10mb to 30mb. It has about 20 versions of app-{hash}.js, 2 of commons-{hash}.js and various numbers of pages.js. It appears to not be quite the same files and they are dated to match previous builds. So it appears like gatsby build somehow have gotten hold of all available old versions and chucked them into /public.

Is anyone able to share a repository?

@roffelsaurus can you try 2.23.22 ?
for us 2.24.2 is failing in ci/cd cypress tests.

Is anyone able to share a repository?

we can share our repo and vars privately, if that's ok to you please ping me an email at konstantin.[email protected] and I will invite you to our gh

@wardpeet you can test this issue in the repository I gave you access related with issue #25766

In my case, the problem was related to the import ordering and the way some libraries (namely react-leaflet) are handled in a server-side rendering environment. We had a leaflet plugin imported before the leaflet itself causing the problem later on. I was able to fix it rather quickly once I knew where to look.

However, I believe that the error message it generated (page resources for / not found. Not rendering React) was incredibly confusing and the lack of details and other errors was the main issue as I had to dig rather deeply to know what it even means.

To anyone else having this problem: How did I find it? Good old breakpointing and debugging in chrome. gatsby build && gatsby serve allowed to see the production environment locally with all the source maps in place. I was able to debug which chunk and then the component is failing to load and mess around with imports inside. It was rather a slow process, so be patient as you will be reloading the page over and over again. Look for your chunk name (in my case it was component---src-pages-index-js) and the import assigned to it. Step into it and observe it's dependencies as one of them will fail. I believe in each case it will be different, so that's why you can't find one good solution anywhere. Source maps came in handy as they showed me more than just a series of generic promises in the array.

This is not the core of the topic, but I'll leave details of what I found out below. Bear in mind though, that below is specific to react-leaflet only and your mileage will vary:

So, this is how it was originally:

import { Map, Marker, Popup, TileLayer } from 'react-leaflet'
import "leaflet-control-geocoder/dist/Control.Geocoder"
import L from "leaflet";

and this is how it looks now:

import { Map, Marker, Popup, TileLayer } from 'react-leaflet'
import L from "leaflet";
import "leaflet-control-geocoder/dist/Control.Geocoder"

Of course, that's an error on our part, as any plugin should usually come after the library it's being plugged into. Since react-leaflet (I think) changes loading order a bit when running debug, the problem was not visible during development.

I just debugged Uncaught (in promise) Error: page resources for /app/ not found. Not rendering React in my app. In my case, /app/ is a client-only route that contains a react app. I had no problems in gatsby develop, but I got this error when running gatsby serve and also on the production build. There were no build errors reported.

Turns out the problems was with react-contextmenu (https://github.com/vkbansal/react-contextmenu/issues/284) which @barbalex ran into as well. I don't know if this is react-contextmenu's "fault" ... it would appear that the library is looking for maintainers and the author was probably focused on the client-side implementation rather than server-side. I don't know if there's anything gatsby can do to make debugging this easier, the error message wasn't very helpful.

@rgembalik, the way I debugged this was by removing all components from my app component, then adding them back one at a time until I found the component that was breaking the build.

For me I can't even replicate, I just see a lot of theses errors in sentry error reporting. so not sure how I will figure out

We're getting a lot of these in Sentry with these errors as well for all sorts of pages other than just "/", also haven't been able to replicate. Hosted on Netlify. I suspect it may have something to do with active sessions during deploys, but hard to verify.

@wardpeet seems like there are a lot of different potential causes that trigger this same error. For us we only see these errors in our Sentry log and have never been able to reproduce. Would it be possible to include more information with the error, or add multiple, more granular errors so we all have something more to go on in trying to hunt down the cause?

I just got this error on https://www.gatsbyjs.com/ ending up with a blank page

I can confirm that on first initial page load I had seen this error on gatsbyjs.com

I figured out that Gatsby has a particular way of handling the url paths with trailing slashes. I don't know if this can help

I am having this issue also.

I am not able to share the repository, but if you access this page you can see it loads an SVG correctly. But, if I go to a route that does not exist, ex https://rocketseat.com.br/test it displays an outdated version of the code (that still uses gatsby-image instead of an SVG) and shows me this message on the console:

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

I am using [email protected]

_edit: I don't know why, but after I added my issue here the image problem was solved, but I continue getting the same error on the page console_

Hard for me to replicate, i just see a ton of these errors in sentry error reporting

@theskillwithin - same. Thousands of these in Sentry.

I'm having the same issue. Very strange. It looks like there are various causes that trigger this error.

We're also seeing this error happen in a variety of browsers and on a variety of pages. I can't seem to relate our situation to any of the aforementioned possible causes. And also I can't seem to replicate in development—it only happens to our deployed website.

I'm having the same issue. not able to replicate but tons of these errors in sentry . also variety of browsers
gatsby version 2.24.3

These are being reported semi-frequently in a production site where I'm using Sentry, too. Unable to replicate myself. The way I see it is we need better reporting. What's bizarre about it is that it does, in fact, find the page data:

Since it is receiving a 200 status, and AFAICT, the json is not malformed, I assume that fetchPageDataJson() is returning a success response:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L137-L151

Since that much seems to be successful, the next point of failure I can see would be loading the component itself:
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L438-L448
https://github.com/gatsbyjs/gatsby/blob/90e66c7fcdc7a75185bdaa336b0f9bdec9762585/packages/gatsby/cache-dir/loader.js#L235-L241

Perhaps there is an issue in the async-requires that are being written out. I imagine those are actually okay, though, since they will be handled by Webpack, and the issue appears to be intermittent. If there were an issue with the way that file is written out, it would cause the build to bomb.

If this were some sort of syntax issue somewhere in the module being imported, then I imagine that it would fail 100% of the time. Perhaps there is something being used in a module that is not compatible with whatever device/browser is loading said module. Hard to tell, for sure, since the specific error is being obscured.

What I think we need is the component loader to _not_ eat the error that is generated.

Having Promise.resolve() there when a chunk doesn't exist in asyncRequires means the error thrown would make sense. That error would also be thrown on every single visit to that page... so it would be easy to track down the cause.

Returning null in the catch block there means that the error thrown does not make sense. The module was found, but an error occurred during the dynamic import. Doesn't webpack return an error in the catch() block of a dynamic import? If it doesn't, then maybe this is an issue that should be taken up with Webpack. I know that if I run a bad import() from devtools, an error is reported... whether or not an error is reported based on the inability/failure to parse the javascript being imported is another question, and would take some additional testing with some code I _know_ won't work in certain browsers.

@wardpeet you mentioned better error reporting previously. Is that in the works, or is help needed?

Regarding browser compatibility, I see these errors mostly generated by mobile devices.

But I've also seen these errors generated on MacOS X using Safari, and Windows 10 using Chrome.

One commonality is that the traffic generally appears to be originating from Facebook or Google. But that may just be coincidence, since those are what drive most of our traffic.

_NOTE: This site I'm working with is actually using [email protected], so code I've linked to is in different places, but the logic itself doesn't seem to have changed. It's still doing the same thing, and the potential points of failure that I've identified seem to be the same._

[email protected]

I also see the error infrequently on bugsnag. Unclear whether the page is rendering or not to me. Here's the stack on bugsnag if its of any help @wardpeet Interesting that in this case it seems to have retried several times. Note this is one of many /webinar/blah... pages we use createPage() on but of course if I try to GET /page-data/... as shown in the photo it works for me.

I'll add some extra info to the logged error so hopefully, we can find the issue

I am experiencing the same issue with a page that originated another bug posted at https://github.com/gatsbyjs/gatsby/issues/26706

In my case it happens in (at least) desktop chrome, and it only happens the first time I load the page, if I hit refresh then everything renders as expected

Then if I try to replicate that first time, even with incognito mode and trying to erase every cache I can think of, I cannot (sometimes I've been able, very random though), until after a while (few days) I visit the url and find the same error (that dissapears after refreshing again)

If I try to replicate it with the same minimal repo I used for the above linked issue I'm not able to see the same errors (at least not the times I have tried now)

The error is (in this case) visible due to the masonry grid not being created, which in my case destroys the page unless the user thinks about refreshing the page (I suspect they don't)

Actually it feels so random that I've been seeing it for few weeks but I've always thought this was something with my pc

I ran npm auidit fix and the problem was fixed for me.

Following! Have the same issue as well

Hi there,

We're having this issue too in production only. We reproduce this bug 100% of the time of specific urls. Let's se the tree structure of our publicdir:

public
  icons
  page-data
  usages
    brainstorming
      page-data.json
    seminaries
      page-data.json

When we enter these urls https://domain.com/usages/brainstorming it works perfectly, https://domain.com/usages/seminaries too. It we enter an unknown url likehttps://domain.com/doesnotexist we rightfully have the 404 page, but if we try to reach an url that match an actual folder in the tree, like https://domain.com/usages, we have this blank page and this error.

Does that may ring a bell to you?

Best

@guillaumepotier do ya'll happen to use nginx as well?

I think it might be caused by faulty response headers.

@daydream05 yes indeed we're using nginx. We saw in our logs some 304 Not modified content headers, and sometimes 200 responses.

using AWS S3 bucket

Same here, hosting in AWS S3 (with CloudFront CDN).

I ran npm audit fix and the problem was fixed for me.

Interesting @liuuuk311. I tried it on our project and possibly it has resolved the issue for us, too. Time will tell, but so far after 48h there are no occurrences in our logs.

Edit: 5 days later, still no occurrences...

Edit: 10 days later and it's occurred a few times again, sorry to report. Running npm audit fix in itself doesn't seem to resolve the issue.

@wardpeet some extra bugsnag data that may help diagnose...

According to these it looks like page-data.json files are actually loading correctly...

• since i stumpled upon this today, i will bump* and watch here.

In my case I fixed the issue loading polyfill.io lib into the page

<script src="https://polyfill.io/v3/polyfill.min.js?version=3.52.1"></script>

@pedrofsantoscom please explain how did staticly loaded script solves an issue for gatsby.js?

Had the same problem yesterday. Clearing cache locally fixed it for the current user. So we cleared cache at Cloudflare and now we don't get any reports anymore.
Clearing cache was our solution

We do not use Cloudflare, we use AWS cloudfront CDN and it gets invalidated after each deploy. I had experienced the bug locally by running local web server with https with first attempt to run after web server starts and also in some consequent page reloads, but not every time. I do not see any pattern. It just happens once in a while.

We do not use Cloudflare, we use AWS cloudfront CDN and it gets invalidated after each deploy. I had experienced the bug locally by running local web server with https with first attempt to run after web server starts and also in some consequent page reloads, but not every time. I do not see any pattern. It just happens once in a while.

That was the solution for us. When we cleared cache did errors per hour reduce fast and we did not get the same error in bugsnag at least. This is indeed a weird error.

I had the same error message but only in Internet Explorer. All other browsers didn't show this kind of error message.

Unhandled promise rejection Error: page resources for / not found. Not rendering React

I traced the issue down to an import I made in my react components. In some cases I had dependencies to the https://sap.github.io/ui5-webcomponents/ . Once i removed those dependencies, the issue went away. I can not explain what the real root cause is, but want to point out that dependencies in your react controls can cause this issue.

@Chaosbohne can't really argue with that, but I would even say it is an issue of sub-dependencies. I guess then gatsby.js team will care for dependency management and security, and in first step will remove ^ from all dependency/devDependency versions, whole range of issues could be prevented.

I can say that this issue is not browser dependent. I've seen it in Chrome and Safari based on Sentry logs, and in chrome 85, 86 locally on my mac.

None of the solutions works. @KyleAMathews because of this issue we are losing business, within 3-4 days this issue happens and we are not able to find out the root cause of it. Please help us find out the solution for this issue.

@R3coN did you try rebuilding your website ? When that happened to us, we basically just tried again (that was a while ago I can't remember why it got fixed)

@R3coN if it can help here's the package versions we use that are working fine:

    "gatsby": "2.20.36",
    "gatsby-cli": "^2.12.54",
    "gatsby-image": "^2.4.13",
    "gatsby-plugin-exclude": "^1.0.2",
    "gatsby-plugin-google-analytics": "^2.3.11",
    "gatsby-plugin-manifest": "^2.4.18",
    "gatsby-plugin-offline": "^3.2.17",
    "gatsby-plugin-react-helmet": "^3.3.10",
    "gatsby-plugin-react-svg": "^3.0.0",
    "gatsby-plugin-resolve-src": "^2.1.0",
    "gatsby-plugin-sass": "^2.3.12",
    "gatsby-plugin-sharp": "^2.6.19",
    "gatsby-plugin-use-query-params": "^1.0.1",
    "gatsby-source-filesystem": "^2.3.19",
    "gatsby-source-graphql": "^2.6.2",
    "gatsby-transformer-sharp": "^2.5.11",

@shide1989 yes, that is the only way to fix it, Rebuilding the website again. But rebuilding also fixes the issue for 2-3 days and then again this issue comes. We are using Gatsby CLI version: 2.12.67 and Gatsby version: 2.24.47 as you have mentioned version 2.20.36 of gatsby is working fine for you, we will try our luck by downgrading the gatsby version.

@shide1989 Thanks for the comment. But downgrading the version throws me this error ->

WebpackError: The result of this StaticQuery could not be fetched.

Which was working in the previous version 2.24.47.

sorry to hear that, maybe you lack a graphql tagged template literal in the same file where useStaticQuery hook is used to extract queries at build time. (as described here : https://github.com/gatsbyjs/gatsby/issues/24526)

anyway good luck with that

But I told you that the same code was working for gatsby 2.24.47.

@R3coN this issue might also be caused by improper static caching. If you’re using nginx or s3 for you server and you don’t invalidate your page-data.json then your StaticQueries will break whenever you change your data.

I had this issue and it turns out I was caching all the page-data.json. They shouldn’t be. They must be revalidated every requests

https://www.gatsbyjs.com/docs/caching/

@daydream05 Thanks for the comment. Yes, I am using S3 with CloudFront. Do you have any idea how to achieve this with Cloudfront?

@daydream05 I already have cache-control: 'public, max-age=0, must-revalidate' added to page-data.json and app-data.json which means that these pages are not cached.

I'm seeing this as well on pages that don't exist (which should load & hydrate the 404 page).

Locally, my dev & production builds work without this error, and when I insert a console.log during the check which throws that error in the built production app-[hash].js, I can see that the page object exists and includes page.componentChunkName: ""component---src-pages-404-js" as I expect that it should.

However, when the app is deployed to gatsby cloud, the error happens on every load of a non-existent page. The SSR'd 404 page is shown in the browser, but then the error is thrown, so React never runs in the browser. When the 404 page is loaded directly (by visiting the /404 path) it works fine, with no error.

This is difficult to diagnose because I haven't been able to replicate it locally so far.

Using latest version: "gatsby": "^2.24.91"

Just posting this here to let others using react-md to quickly fix their site, or hoping this could help in anyway to fix this issue in Gatsby.

I had the same error in one of my projects, where I was using react-md
After removing all of the components I could get rid of the issue.

Since I had to deploy to prod every time to test this, I haven't managed it to pinpoint which specific component has this issue, but I have narrowed it down to.

import Card from "react-md/lib/Cards/Card";
import CardTitle from "react-md/lib/Cards/CardTitle";
import CardText from "react-md/lib/Cards/CardText";
import CardActions from "react-md/lib/Cards/CardActions";
import { TextField, Button, Snackbar } from "react-md";

I ll be updating my blog post about this issue if I get time to dig deeper.

Regarding 404 pages, I can confirm @aMoniker 's issue as the same pattern of behavior is happening for me.

Locally, both develop and production builds work fine with the 404 page, but when deployed to Gatsby Cloud, I get the issue on every unknown page except the actual /404 path.

I've also encountered this error and fixed it by clearing browser cache. However it would be good to find a solution that does not require that, as we can't force all our uses to do this.

@dejavu1987 we are not using react-md on projects experiencing this issue.

@MaciekBaron I had reproduced an error locally by clearing browser cache multiple times and reload the page after each clear.

This seems to be caching issue as I mentioned earlier. If your cache headers are all set properly, the issue might be with service workers.

Maybe give this plugin a try?
https://www.npmjs.com/package/gatsby-plugin-remove-serviceworker

Hey I run also into this issue. In develop everything is working fine but when I run gatsby build and deploy the public directory to my web hoster then a page fails working because of this error message.

I was very curious about and looked into the public page-data directory. I found that the specific page directory exists but it was not in small letter instead the directory was in capital letter. That was the problem I've got the error message.

After that I changed it to small letter at the beginning and its working fine in prod. I think this occurs because I changed the name of the page earlier & maybe something is cached here?

I also run into this issue. I have found a method to fix this issue. But I think it hasn't fixed the true problem.

Now, let me explain how to fix it.

This issue was found in the test or production environment，as all above say, it won't reproduce in development. Even in test or production, it didn't occur every time. And I found that all the scripts were preloaded and executed asynchronously. So I guess it may be caused by the executive order of the scripts.

As I slow down the network in Network, such as set as 3G fast, the issue almost occurred every time. This confirmed my guess.

To valid my guess, I have changed the process of render HTML in gatsby-ssr.js to set all script without "async", as follow:

exports.onPreRenderHTML = ({ replacePostBodyComponents, getPostBodyComponents }) => {
    const postBodyComponents = getPostBodyComponents()
    postBodyComponents.forEach((component) => {
      if(component.type === 'script' && component.props) {
        delete component.props.async
      }
    })
    replacePostBodyComponents(postBodyComponents)
  }

Happily, it works.

Even though this way can help fix the issue, I don't think it is a good way to do this. It seems like violating the feature of gatsby. Is the script execute asynchronously design to be like this?

Hopefully, this way can solve all of your problems as well.

This issue was found in the test or production environment，as all above say, it won't reproduce in development. Even in test or production, it didn't occur every time. And I found that all the scripts were preloaded and executed asynchronously. So I guess it may be caused by the executive order of the scripts.

Even though this way can help fix the issue, I don't think it is a good way to do this. It seems like violating the feature of gatsby. Is the script execute asynchronously design to be like this?

I think you are right, I had this issue coming back for strange reasons.
The latest one was wild, but when I connect it to your answer, it makes sense.

So, recently I added a font icon component to my layout component, and it reproduced this issue.
An important point to note is, the font icons have been used in other deep nested components all this time, and it never caused the issue, only when it's on the layout level which is the first component called from any page component.

I might be wrong but this could be a good scenario to figure out the actual cause.

@dejavu1987 Agree with you. Maybe you have given a good scenario to figure out the actual cause.

Furthermore, I wonder if it is suitable to load and execute the scripts with async, as webpack split codes into different chunks but the chunks may have dependencies.

The main issue seems to be that Gatsby swallows errors during page loading and just reports the very generic page resources for / not found. Not rendering React message, which is why there are so many different potential causes reported in this thread.

My issue turned out to be that Mobx 5 does not support IE11, and while Mobx provides a nice error message for this, all I got was the "page resources not found" message from Gatsby which was rather misleading.

I'd humbly suggest as the resolution of this issue to report the original error message that caused the page loading to fail. @wardpeet

What fixed it for me is that I had S3 set up to return a 200 on the 404 page. When I changed it to return a 404 status code it worked.

Yes I found this as well. However, my issue was broader… I was improperly caching on Cloudfront 404 results. The reason I was getting 404 results between Cloudfront and S3 is that the deployment to S3 via CodePipeline I believe unzips the Build Artifact ZIP file - but it doesn’t do it in any particular order. So for a few minutes you can have new .HTML files pointing at new .JS files (with new hashes) which aren’t there yet. Whatever handles caching for your hashed asset files must not cache on 404 results as this can only be corrected by flushing your CDN cache.

Has anybody figured out how to make sure HTML files are deployed to S3 last by the way?

David
https://ewebinar.com

On Oct 21, 2020, at 12:40 PM, Vince P. notifications@github.com wrote:

@R3coN https://github.com/R3coN this issue might also be caused by improper static caching. If you’re using nginx or s3 for you server and you don’t invalidate your page-data.json then your StaticQueries will break whenever you change your data.

I had this issue and it turns out I was caching all the page-data.json. They shouldn’t be. They must be revalidated every requests

https://www.gatsbyjs.com/docs/caching/ https://www.gatsbyjs.com/docs/caching/
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/gatsbyjs/gatsby/issues/19618#issuecomment-713298516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3SHT55MXZTXQUAXH5ZUY3SLZQ4VANCNFSM4JPB5IKQ.

I can add that I had reproduced an issue with chrome Lighthouse Audit on mobile testing, with PWA tests and without. I'm sure mobile tests uses network and cpu limits, so async scripts loading out of order, or one of 30 failing... could be pretty often situation.

I'm working with 3d, and even at localhost with webpack and gatsby.js, reloading the page pretty often results in failed network requests for static model gtlf files. One of them has failed - all app is broken (if no ErrorBoundary set).

I guess here could be the same pattern, but without proper error handling.

I'm using S3 and CloudFront for production. I had a similar issue but in my case I was getting Can't render React error in console only on Cloudfront. This started to happen after changing files on the production S3. To my surprise problem solved after re-running lighthouse for production origin.

This was only happening on my device in normal mode. In my case cleaning the whole cache, cookies, localstorage, session storage and service workers didn't help earlier.

So if you profile your production origin with lighthouse and files were changed this problem may also occurs ( In my case, it was )

My point is that I can reproduce it with lighthouse pretty much 1 from 10, and last deploy was long time ago.

I don't think gatsby will be able to solve this problem, because this is happening to everyone but the reason is different. I get blank pages too often or whenever I change something in the backend gatsby page goes blank and throws an error, and that error too is different every time. I think we have to stop using gatsby and switch to some other reliable framework.

I could fix the error if there is any way to reproduce it, but there is not. This error happens randomly, sometimes it happens a day after I deploy, Sometimes it happens 3-4 days after the deployment. But it happens.

@antoinerousseau Did you find anything? Can anyone tell me step by step how to debug this issue at least? I have tried all the things from my side but 1-2 days after deploying the website breaks. Can anyone tell me how to know when this issue will happen because for me it happens too randomly?

What fixed it for me is that I had S3 set up to return a 200 on the 404 page. When I changed it to return a 404 status code it worked.

S3 or Cloudfront?

In my case the problem was in 404 page, used by default by Azure. It was blocking error and the only thing i was able to see in console was
Error / page resources for / not found. Not rendering React

Since i started to use custom 404 - problem gone.

I get the same when I deploy the app on Netlify.. Locally Gatsy Build and Gatsby Serve works well.. This is even more stranger..

@atapas can you please contact Netlify support? may be they can clarify something from their side?

@atapas can you please contact Netlify support? may be they can clarify something from their side?

Yes, I did. Thanks!

Maybe, a better stack trace or clear error message would be helpful here. Anyways, thanks for the response.

@atapas I'm not a member of a team, just suffering the same bug as you.

I get the same when I deploy the app on Netlify.. Locally Gatsy Build and Gatsby Serve works well.. This is even more stranger..

I've found the solution in a completely different context. I was getting the error because Netlify was ignoring the env variables I had set for Auth0 to work in my app,

domain: process.env.AUTH0_DOMAIN,
clientID: process.env.AUTH0_CLIENTID,
redirectUri: process.env.AUTH0_CALLBACK,

I later read about the "Deploy without sensitive variables" from here and fixed it as it was mentioned in the doc.

I'm surprised with the error I got and the solution landed into.. but glad it worked.

@atapas I'm not a member of a team, just suffering the same bug as you.

@JustFly1984, No worries I really wanted to Thank You. I looked into Netlify doc and could figure out the solution as mentioned in the above comment.

I'm getting this only in Chrome. Safari works great. I just added the offline and manifest plugins to my project. I can't reproduce it with Gatsby develop or with gatsby build & gatsby serve locally. I'm hosting on Netlify.

For me this block of code outside of my React component as well as referencing the global variables in the React component was causing the error. Removing it fixed the issue.

let deferredprompt = null;
let updateAvailable = false;
if (
  typeof window !== "undefined" &&
  window.hasOwnProperty("BeforeInstallPromptEvent")
) {
  window.addEventListener("beforeinstallprompt", (event) => {
    deferredprompt = event;
    event.preventDefault();
  });
}

if (typeof window !== "undefined" && window.isUpdateAvailable) {
  window.isUpdateAvailable.then(
    (isAvailable) => (updateAvailable = isAvailable)
  );
}