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

Still an issue.

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

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

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.

It’s super difficult for us to find out why this is happening. I’ve created a PR that should give us more insights in the why it fails.

https://github.com/gatsbyjs/gatsby/pull/29970

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

It hasn’t been fixed. This issue is umbrella for SSR and network bugs.

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

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)

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

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

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.

Most recent	On Android, w/ chrome

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 gatsby@2.24.2, 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.

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

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

I’ve had the same error. My problem was that there was still an old service worker registered.

After I’ve unregistered the worker (Chrome > Dev Tools > Application > Service Workers > Button Unregister) everything worked fine.

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

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

Please fix it!

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

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

Please fix it!

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!

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.

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

“gatsby”: “^2.23.11”

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.

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

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.

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.

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

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

Following! Have the same issue as well

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

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.

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

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.

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.

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)
  

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:

I am unsure of how or why this appeared, but, with Gatsby, I did the following to fix it:

1. gatsby clean
2. gatsby build && gatsby serve

When I inspected the code the error went away for some reason beyond my knowledge. I got the error when sourcing posts from my Wordpress’ REST API.

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

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

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"

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

But I told you that the same code was working for gatsby 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

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

@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",

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.

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

I think it might be caused by faulty response headers.

@theskillwithin - same. Thousands of these in Sentry.

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

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.

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.

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

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

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: