Gatsby: Missing resources for /

Might be related to https://github.com/gatsbyjs/gatsby/issues/11453

Maybe, though there's no 404 stuff involved here.

Sorry you're seeing this, @Jivings

Could you please link to a minimal reproduction if possible?

I haven't been able to reproduce locally 🙁 Is there any more information I can get you, or does the sentry report help at all? Under what circumstances might this occur so that I may be able to narrow it down?

I am also seeing this but only after deploying, I can't reproduce locally.

Uncaught Error: Missing resources for /store/
    at t.n.render (ensure-resources.js:135)
    at Xo (react-dom.production.min.js:156)
    at Qo (react-dom.production.min.js:155)
    at ti (react-dom.production.min.js:162)
    at Oi (react-dom.production.min.js:192)
    at ji (react-dom.production.min.js:193)
    at fa (react-dom.production.min.js:205)
    at sa (react-dom.production.min.js:204)
    at Mi (react-dom.production.min.js:200)
    at ya (react-dom.production.min.js:218)

I have noticed though that I only get this error on a branch where I tried to removed ThemeProvider (styled-components) from my code and I am guessing somewhere things got messed up in the file structure since no packages were added/updated/removed. Will update if I pinpoint the cause but there isn't much to go by.

I am having the same issue here... first, sorry for my english, i'm spanish-speaker ¯_(ツ)_/¯

Error: Missing resources for /...
    at t.n.render (ensure-resources.js:135)
    at Ri (react-dom.production.min.js:169)
    at Ci (react-dom.production.min.js:168)
    at Li (react-dom.production.min.js:176)
    at Ba (react-dom.production.min.js:221)
    at Ha (react-dom.production.min.js:222)
    at Pl (react-dom.production.min.js:238)
    at Tl (react-dom.production.min.js:237)
    at wl (react-dom.production.min.js:234)
    at Qa (react-dom.production.min.js:232)

First of all, a little of context, I had an issue related to a carousel package Tiny Slider which was using window, so I search for different carousels with SSR implemented and I found react-responsive-carousel. I works great with what I needed, but only in develop.

The mentioned error happens in two related scenarios:

Scenario 1
I use styled-components to style my slide, but adding mixins broke my builds. I found that adding gatsby-plugin-styled-components solved the issue; and it works, but... scenario 2 happend

Scenario 2
Now my build is working and I can see my page with styles. But, my carousel does not work, it does nothing!!! 😱... The styles are looking great though... 😅
So I just remove the gatsby-plugin-styled-components and the script worked again, but not my styles 🙃

Hope this gives some hints to find and solve the issue

Hi Guys.

Not sure if this helps but I had a similar issue, it turns out my missing resource was a missing (production) env variable for firebase. This in turn seemed to effect my images - this must have had an impact on a build step

Can provide more information if required...

@Jivings can you update gatsby and gatsby-plugin-offline package? this happens when you make new build but resources from previous are no longer available (so html cached by offline plugin tries to use not available resources). In newer gatsby/offline packages versions we added reload after service worker updates to not leave site in unusable state

In my case, I changed an import from import { Link } from './' to import { Link } from './Link' (in my file /components/footer.js), and it did fix the error "Missing resources for /". It was a circular dependency I guess. But I don't know if it will fix yours
Edit: If the error happens periodically, I think the solution from @pieh above have better chances to fix it.

I'm getting these errors but only in IE11. I'm not sure exactly which resources are failing since it's only occurring in one browser, as far as I can tell, but I do see some errors in react-dom (see screenshots below). I updated all of my Gatsby dependencies to their latest versions and added a polyfill in case it was choking on Symbol or something too modern, yet the errors still occur. I also have image loading problems in IE11, too, I believe like what is discussed in #4021. If I remove all images and the offline plugin, I get no errors on page load but I do when I navigate to any other pages, even if they don't contain images. It looks like some JS fails to load and IE presents probably the HTML 404 page instead. So there's definitely something wonky going on here.

I'm working off of my develop branch deployed to Netlify to test out fixes on various devices.
Here's the latest debug build if you want to test it: https://5c6ee3b943e6c400080a5a8b--marcysutton.netlify.com/about/
Here's my live site, which definitely has all of the brokenness in IE11 still: https://marcysutton.com
And here's my site source: https://github.com/marcysutton/gatsby-site

Here are some screenshots from my VM:

@marcysutton Have you made any headway with this? I'm seeing the same thing in IE11 only. No issues in any other browsers.

Not yet! @sidharthachatterjee or @pieh, is this enough information to debug? Pretty blocking issue in IE11 at the moment.

@Undistraction I have some good news: the team helped me debug this issue, and they pointed out that IE11 is having trouble with uncompiled arrow functions in a plugin (gatsby-background-image). They're discussing changes to Gatsby core to account for this, but in the meantime you should be able to get around it by compiling any plugins that are causing issues: https://www.gatsbyjs.org/packages/gatsby-plugin-compile-es6-packages/?=compile

Here's where I used it on my site: https://github.com/marcysutton/gatsby-site/blob/develop/gatsby-config.js#L107

Let us know if you still have any trouble!

Same issue here, seeing this periodically on websites I haven't visited for a few days (the Gatsby website as well). Not on IE11 but Chrome. After a few seconds of blank page, there's a refresh after which everything is working again.

Versions of one example:
gatsby: 2.0.118
gatsby-plugin-offline: 2.0.23

I am getting this error in IE (edge mode).

It is pointing to the file react-dom.production.min.js in line 1 char 195183.

when clicking on the error in IE it points to this code:

if(pi)throw a=qi,qi=null,pi=!1,a;}

@marcysutton Thanks for the update. I hadn't spotted that syntax error in your console. For us we have no error at all. The page navigation is completely broken in IE11, and the page doesn't hydrate. On a page refresh we do get the missing resources error. We've had to drop IE11 support because there is nothing to go on. No issues with any other browser. My hunch is that this is a polyfill issue, but that the error is being swallowed somewhere, but that's just a guess. I don't understand how the page hydration can crash without any error in the console.

I am getting this error on (1st) load. Seems to clear after reload. Production / Firebase hosting.
Error: Missing resources for /

@rkhayat could you link to a URL or better yet provide a reproduction?

Thanks!

FWIW I wrote up my experience with this issue in https://github.com/gatsbyjs/gatsby/issues/12399 It might be of help to anyone hitting the Missing resources for / error.

I was having what seems like a similar issue: One could navigate the site fine, but on any page, if they did a refresh, the page would be blank and I'd see Error: Missing resources for /<path>. A hard refresh or clearing of cache would reload the page, but again normal refreshes would show a blank page.

Not being able to reproduce this locally with gatsby server, I suspected it was a CDN issue, so I invalidated the root directory in my CloudFront distribution which seems to have resolved this issue for me. I'm still not sure exactly what was happening, but suspect some references got outdated. Hope this helps someone else.

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!

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

@gatsbyjs-read-only-user Not stale 😬

@Undistraction I have some good news: the team helped me debug this issue, and they pointed out that IE11 is having trouble with uncompiled arrow functions in a plugin (gatsby-background-image). They're discussing changes to Gatsby core to account for this, but in the meantime you should be able to get around it by compiling any plugins that are causing issues: https://www.gatsbyjs.org/packages/gatsby-plugin-compile-es6-packages/?=compile

Here's where I used it on my site: https://github.com/marcysutton/gatsby-site/blob/develop/gatsby-config.js#L107

Let us know if you still have any trouble!

@marcysutton How did you identify the plugins/modules that contain uncompiled arrow functions?

@onetwothreebutter open the compiled JavaScript file(s) in the browser and search for =>. IE didn't make it easy to tell where they were coming from, so I just searched manually with "Ctrl + F"

This should improve in core over time but that's how you can check in the meantime!

Would like to add that this problem persists for us across all browsers and version, it's not just IE, and seems to be triggered by using a Service Worker in Gatsby. Related: #12399

I have also faced the same issue.

• If the service worker is enabled , refreshing the pages causes the above mentioned errors. This issue primarily was appearing on Chrome. The Edge browser seems to work fine (probably because the service worker does not come into play there)
• On removing the service worker and using the plugin gatsby-plugin-remove-serviceworker this issue goes away
  Resolution Used:
• However given the importance of having the server worker functional tried out the plugin gatsby-plugin-remove-trailing-slashes in combination with PWA plugin gatsby-plugin-offline and this seems to resolve the issue for me.

I'm having this error and I'm not using a service worker.
I was thinking that maybe it happens if the page loads with a certain version of the site, and then a deploy is done and the asset names change so they can't be found by the opened version?
Besides, the version causing the Error in Sentry is not the version that was live at the moment of the Error.

@antoinerousseau Yeah, after a few attempts at trying to fix it we still get it even without the SW. We did upgrade a few Gatsby plugins to recent versions and it reduced the count of errors, but not to 0. (Could well be coincidence though)

@KyleAMathews Have you been seeing this, or have any info?

@jackhair it's hard to tell what's happening without a reproduction. http://gatsby.dev/reproduction

Workaround: https://github.com/gatsbyjs/gatsby/issues/13410#issuecomment-486306784

@smakosh I'm not using service workers.

The offline plugin is using it

Ok but what I mean is that the bug happens even without that plugin.

Can you check that you've successfully unregistered the SW as maybe you have used it before, try also clearing your Gatsby cache by deleting the public and .cache folders

Never used any SW on that project. (and just checked just in case)
public and .cache are always recreated by Netlify.
Errors are being reported in production by Sentry.
https://sentry.io/share/issue/738b234836814442b7702866c6814fdf/

Is your project open sourced? if so can you link below, I'd love to check it out and see how I can fix that

Sorry it's not, but basically it's a Gatsby site served by Netlify...

  "dependencies": {
    "@sentry/browser": "^5.1.1",
    "@types/algoliasearch": "^3.30.8",
    "@types/dotenv": "^6.1.0",
    "@types/he": "^1.1.0",
    "@types/jump.js": "^1.0.2",
    "@types/node": "^11.13.7",
    "@types/node-fetch": "^2.3.3",
    "@types/react": "^16.8.14",
    "@types/react-dom": "^16.8.4",
    "@types/source-map-support": "^0.5.0",
    "@types/standard-http-error": "^2.0.0",
    "@types/styled-components": "^4.1.14",
    "algoliasearch": "^3.32.0",
    "aws-sdk": "^2.443.0",
    "babel-plugin-styled-components": "^1.10.0",
    "date-fns": "^2.0.0-alpha.27",
    "gatsby": "^2.3.31",
    "gatsby-image": "^2.0.40",
    "gatsby-plugin-google-analytics": "^2.0.18",
    "gatsby-plugin-manifest": "^2.0.29",
    "gatsby-plugin-netlify": "^2.0.15",
    "gatsby-plugin-offline": "^2.0.24",
    "gatsby-plugin-react-helmet": "^3.0.12",
    "gatsby-plugin-sharp": "^2.0.35",
    "gatsby-plugin-styled-components": "^3.0.6",
    "gatsby-plugin-typescript": "^2.0.13",
    "gatsby-source-filesystem": "^2.0.32",
    "gatsby-transformer-sharp": "^2.1.18",
    "he": "^1.2.0",
    "hyphenslug": "^1.0.0",
    "intersection-observer": "^0.6.0",
    "jump.js": "^1.0.2",
    "mkdirp2": "^1.0.4",
    "mustache": "^3.0.1",
    "node-fetch": "^2.3.0",
    "nodemailer": "^6.1.1",
    "prop-types": "^15.7.2",
    "react": "^16.8.3",
    "react-dom": "^16.8.3",
    "react-helmet": "^5.2.0",
    "sitemap": "^2.1.0",
    "source-map-support": "^0.5.12",
    "standard-http-error": "^2.0.1",
    "strip": "^3.0.0",
    "styled-components": "^4.1.3",
    "ts-node": "^8.1.0",
    "typescript": "^3.4.5",
    "whatwg-fetch": "^3.0.0"
  },

I'm seeing the offline plugin installed, can you confirm it's not included in your gatsby-config file?

Yes sorry but not used, here is my Gatsby config:

module.exports = {
  siteMetadata: {/*...*/},
  plugins: [
    `gatsby-plugin-typescript`,
    `gatsby-plugin-styled-components`,
    `gatsby-plugin-react-helmet`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images`,
      },
    },
    {
      resolve: `gatsby-plugin-sharp`,
      options: {
        defaultQuality: 80,
      },
    },
    `gatsby-transformer-sharp`,
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: `Le Bikini`,
        short_name: `Le Bikini`,
        start_url: `/`,
        background_color: `#000000`,
        theme_color: `#000000`,
        display: `minimal-ui`,
        icon: `src/images/favicon.png`,
      },
    },
    `gatsby-plugin-netlify`,
    {
      resolve: `gatsby-plugin-google-analytics`,
      options: {
        trackingId: process.env.GOOGLE_ANALYTICS,
        head: false,
        anonymize: true,
        respectDNT: true,
      },
    },

    // this (optional) plugin enables Progressive Web App + Offline functionality
    // 'gatsby-plugin-offline',
    // To learn more, visit: https://gatsby.app/offline
  ],
}

And you can see it live at https://lebikini.netlify.com

I can't help without a reproduction repository as I need to check more stuff to debug

be careful @antoinerousseau
gatsby-plugin-netlify plugin should be the last in the plugin array according to the plugin documentation
https://www.npmjs.com/package/gatsby-plugin-netlify

@abumalick @antoinerousseau We move gatsby-plugin-netlify to the end of our plugin array, and it didn't change anything.

Perhaps this may have something to do with it? https://github.com/gatsbyjs/gatsby/issues/11982

When ever I've come across the problem myself (pure chance), it always has some kind of error to do with pages-manifest missing.

I've outlined the only fix that works in all cases in a related issue here: https://github.com/gatsbyjs/gatsby/issues/12399#issuecomment-488247566

I had the same issue. My case was the same as @efd1 - import in form of import { Module } from "." was breaking my production build (development was working without any issue). It was not very easy to debug and find unfortunately.

The suggestions above doesn't seem to work for me. I'm only seeing this for iOS users and only sporadically. I can't seem to replicate it and thus it's hard to figure out what might be wrong. Any tips on how to figure out what the underlying problem might be?

To echo Kyle's statement above, we need reproducible demo sites to be able to help. http://gatsby.dev/reproduction

it's hard to tell what's happening without a reproduction. http://gatsby.dev/reproduction

@KyleAMathews Honestly, I think this happens on every Gatsby site deployed to Netlify that is multiple pages. Throw Sentry up on one and see for yourself.

I'd say this statement is a bit premature as for example all my Gatsby projects are deployed to Netlify and I've never seen the error (in the last couple of months). A reproduction would be really helpful indeed.

@LekoArts @marcysutton The Sentry trace is still publicly available here.

Does that help at all?

The error occurs on my production site approximately once per day.

I'd say this statement is a bit premature as for example all my Gatsby projects are deployed to Netlify and I've never seen the error (in the last couple of months). A reproduction would be really helpful indeed.

@lekoarts Do you have Sentry setup? How much traffic?

The error occurs on my production site approximately once per day.

@Jivings How much traffic? I'm trying to get an idea of frequency.

As best as I can tell I've caught 541 instances of this error since March 1 across 160k pageviews (47k sessions) on one website I maintain. That's an 0.3% chance of a pageview triggering the behavior, or a 1.2% chance of a session experiencing it. Not great as far as reproductions are concerned; we'll likely need old-fashioned traces, sleuthing, and other debugging to ferret this out.

It's more common on mobile devices, but more of their visits are from mobile, and it happens on desktop too. Make/model/browser appears to be irrelevant. For what it's worth, this is a streaming audio platform, so we tend to see much longer session durations than websites that are marketing focused or see a lot of in-and-out traffic.

Is anybody seeing this error in production _without_ using Sentry? Anybody using Honeybadger, Raygun, Rollbar, Airbrake, or similar?

@coreyward Also seeing it intermittently with Raygun. It's only on one specific page and effects Mobile Safari and Chrome only.

@coreyward We use Bugsnag and have seen it around 4.8k times in the last month.

@coreyward Maybe this is helpful:

(from https://github.com/gatsbyjs/gatsby/issues/12399#issuecomment-480082161)

We use Bugsnag and are seeing this show up for about 1% of traffic. Browsers seem to roughly match our overall traffic distribution—not seeing any clear patterns there.

@coreyward Looks to affect around 1% of traffic for us.

@KyleAMathews Hey I just ran into this error on the production GatsbyJS website. After refreshing a couple times the issue went away.

We have been facing this issue when using the offline plugin and deployment on Azure blob storage plus the CDN. I was reading that the service worker js must not be serviced from the CDN and should be coming directly from the server domain. May be that's the root cause.

We have ers-hcl.github.io that's deployed with the offline plugin and service worker enabled on ghpages .Never faced this issue there which probably points to my earlier comment in terms of the issue being related to the CDN handling of the offline plugin

this issue has nothing to do with the offline plugin. And if you're using the offline plugin, make sure to reload or show a push notification to users that new content is available to update the SW.

@smakosh whenever we disable the offline plugin this issue goes away for us.

We are seeing it and we don't use the offline plugin.

• I may be wrong - one observation in the file ensure-resources.js, which is the component which throws this error but thought of mentioning just in case.
• Looking at the code for ensure-resources.js , it seems to be using window.location on line no 81, where as there is a property location which is being used in this component in all the other places.

I doubt our particular situation will be helpful for many other folks, but I wanted to share it here just in case.

This was affecting DataCamp.com due to a CORS issue. We are using asset-prefixing and hosting assets on S3, served via Cloudfront. During our first deploy with asset-prefixing, we forgot to set CORS headers in S3 to allow access to the assets from our domain (oops). We updated our CORS headers after a minute or two, but any edge nodes where the assets were already called apparently cached not just the asset content but also the CORS headers! This created the illusion that some weird bug was affecting only a small percentage of users, when in reality the issue was that a small percentage of edge nodes had the old headers cached. We solved this issue by creating an invalidation in Cloudfront for all of the assets.

More generally: if any of your users have an adblocker that is picking up a particular asset name as potentially being advertising or tracking related, if at any point between your asset server and the end user there's a middleman that might be modifying headers for a small percentage of your users (e.g. a corporate network that filters content), or if any other weird network thing might be happening, it seems like all of these could contribute to this error.

We had this same issue and it turns out the main reason behind it was circular dependencies

@bigfanjs could you go into a little more detail there?

@DSchau Well recently a teammate added a feature and we deployed, the browser starts complaining with a similar issue, we didn't have an idea, my teammate created a page and a big common reusable component. So we commented the code in both the page and the component, and rather rendered a <div /> tag. And ran gatsby build and then gatsby serve in order to server production build locally. and we started narrowing down by commenting some code and run the above commends each time. like:

import {Button} from "components/kit"

// comment the rest to see if `Button` is causing the issue
// import {Box} from "components/kit"
// import {Form} from "components/kit" 

next time we comment Box and so on...

So finally turns out the error is simple.

We have common component called kit which imports a couple components:

components/kit

| --- Box.js
| --- Button.js
| --- Form.js
| --- index.js

index.js

export { default as Box } from "./Box"
export { default as Button } from "./Button"
export { default as Form } from "./Form"

for example inside Form we were trying to import Box this way:
import {Box} from "components/kit"

But that causes the issue, we changed it something like:
import {Box} from "./Box"

and it worked.

hope that helps.

Same issue here, seeing this periodically on websites I haven't visited for a few days (the Gatsby website as well). Not on IE11 but Chrome. After a few seconds of blank page, there's a refresh after which everything is working again.

Versions of one example:
gatsby: 2.0.118
gatsby-plugin-offline: 2.0.23

I had a similar error with this one. And I couldn't access netlify cms admin page on production build.
And I found that this is because of gatsby and gatbsy-plugin-offline version mismatch finally.
thumbs up!!!

For people who see this error occasionally — that's to be expected actually — whenever you deploy a new version of your site, most hosts delete older versions of the site which means that anyone already on the site that tries to navigate to a page won't be able to find the resources for this page so will throw this error and then trigger a full refresh by grabbing the HTML anew for the page.

You can see the tests for this here: https://github.com/gatsbyjs/gatsby/blob/cbbed1dde8a4fd25080e9ab65d7661dfa8fbf327/e2e-tests/production-runtime/cypress/integration/resource-loading-resilience.js#L57

@KyleAMathews It appears the refresh is not being triggered by this missing resources error, so a user is stuck on a broken or just white page. Do we need to have the offline plugin to ensure the refresh happens?

No... if that's happening then it's a bug in Gatsby. Do we have a reproduction for the scenario you're describing?

--
Kyle Mathews

Blog: http://bricolage.io
Twitter: http://twitter.com/kylemathews

On Tue, Jun 04, 2019 at 3:05 PM, Jack < [email protected] > wrote:

@ KyleAMathews ( https://github.com/KyleAMathews ) It appears the refresh
is not being triggered by this missing resources error, so a user is stuck
on a broken or just white page. Do we need to have the offline plugin to
ensure the refresh happens?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
https://github.com/gatsbyjs/gatsby/issues/11524?email_source=notifications&email_token=AAARLB6OVB47GMB5K2242M3PY3RLFA5CNFSM4GUAYCZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW6AHWI#issuecomment-498861017
) , or mute the thread (
https://github.com/notifications/unsubscribe-auth/AAARLB7QKXUL3AZF4MXCO33PY3RLFANCNFSM4GUAYCZA
).

@KyleAMathews Other than catching it hit-or-miss on our production site, I've been unable to reproduce it locally. A reproduction would require setting up an entirely new repo w/ Netlify integration, then keep pushing updates until eventually you come across it.

It does appears @coreyward caught it on the Gatsby site further up in the comments.

Also relevant to this discussion is @Moocar has been working on a large refactor of how we load data in the runtime https://github.com/gatsbyjs/gatsby/pull/13004

I don’t have a reproduction at the moment, but I can confirm that I’ve seen this at least half a dozen times where it didn’t refresh on its own.

@KyleAMathews we're seeing this happen to 1% of requests across all browsers completely independent of when we deploy—we'll see it happen on Sundays at the same rate even when the last deploy was on Friday. Here's a bugsnag screenshot to illustrate the relative consistency over time (of course still some small amount of lumpiness from normal traffic variation):

@gwlortscher very interesting — so doesn't seem related to deploys then. It's looking like this chart is one that's showing counts of the error. Could you share a chart that's of the % of requests? That I assume isn't varying with traffic?

Just to add a possible cause:
In my case, it was a new Buffer(val, 'base64').toString(); as a replacement for atob in SSR.
(Basically if atob is not available, use the node-js version.)
Worked in develop, compiled correctly, crashed on startup of the prod-page. Further, the include was enough, the code was never executed, it was just present in the chunk that would be loaded on startup.

@KyleAMathews Bugsnag doesn't appear to have a % requests chart but easy enough to calculate from analytics. Here are the past 8 days (errors as a percentage of requests):

6/1 2.4%
6/2 2.3%
6/3 2.2%
6/4 2.4%
6/5 2.4%
6/6 2.1%
6/7 2.4%
6/8 2.4%

We first saw this happen when upgrading to Gatsby v2.9.4. Reverting to 2.8.5 resolved the issue. Still trying to analyze the cause.

We had this same issue and also saw it fixed by downgrading to 2.8.5. Before doing so, we were constantly getting errors for Missing Resources for "/"

@bmatzner @wilcoxmd We've been on 2.8.x for a while, and have been having Missing Resources in every Gatsby upgrade since we first moved from v1 to v2. Consistently, no spike or change when upgrading since v2.

We've definitely been seeing for a long while before 2.8.5. I think this issue has a wide variety of causes. v2.94 just seems to have introduced yet another.

@bmatzner @wilcoxmd We've been on 2.8.x for a while, and have been having Missing Resources in every Gatsby upgrade since we first moved from v1 to v2. Consistently, no spike or change when upgrading since v2.

Same

@jackhair I see. We haven't launched our Gatsby site yet, so I don't know if we'll still see some percent of traffic see this issue. We encountered this when deploying a staging version. We were on 2.9.2 and things were fine with serving a build locally, but as soon as we deployed it we had a permanent missing resources error on any browser. Downgrading to 2.8.5 just allowed me to deploy and have the site start to work.

@jackhair I see. We haven't launched our Gatsby site yet, so I don't know if we'll still see some percent of traffic see this issue. We encountered this when deploying a staging version. We were on 2.9.2 and things were fine with serving a build locally, but as soon as we deployed it we had a permanent missing resources error on any browser. Downgrading to 2.8.5 just allowed me to deploy and have the site start to work.

Interesting. For what it's worth, we have never been able to replicate the issue locally (gatsby develop), only when it's built on a production environment do we see the issue.

We have a prod branch on 2.9.2 that looks promising, so far no issues, but the traffic to it is miniscule compared to main production. I'll post results once we've deployed, hoping the page manifest update to Gatsby last week helps a lot.

We have 2.9.0 in production and unfortunately are still seeing the issue at the same rate as before—1-2% of traffic across all browsers.

The version rollback down to 2.8.5 from 2.9.4 seems to have fixed the issue for us.
In our case it seems to be related to some missing pages-manifest-{hash}.js[.map] files.
The 2.9.3 and 2.9.4 version have some potential breaking changes: see https://github.com/gatsbyjs/gatsby/pull/14732 (from Gatsby package changelogs: https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/CHANGELOG.md).
For confirming this a last test for us should be to upgrade Gatsby up to 2.9.2.

FYI @moocar has a PR up to make resource loading more robust e.g. retry failed or partially loaded resources https://github.com/gatsbyjs/gatsby/pull/14889

If any of you have time to review / try that, it'd be much appreciated. I apologize for not catching this earlier — it wasn't clear how widespread this was or what the cause was before digging in recently with @Moocar

I don't know whether it'll help more, but I had it on https://gatsbyjs.org/contributing a few minutes ago:

Was fixed after a reload, but seemed worth to put here @KyleAMathews

I believe this could be an issue with the offline plugin configuration, since it might not be correctly checking for changes with page manifest files, and therefore keeping old ones about.

Going to try and look at this next week with @wardpeet since I've written a lot of the offline plugin - sadly I've been really busy recently with exams and planning to move house so haven't been able to check out all these changes properly 😞

@davidbailey00 Before you get too deep in debugging, we experience this with or without the offline plugin.

@davidbailey00 we also were having the issue without the offline plugin. It is in my node modules, but still commented out of my config file.

We are also experiencing this without the offline plugin installed.

@davidbailey00 yeah we think the main fix is correctly handling some unusual error cases for ajax requests & adding retry logic https://github.com/gatsbyjs/gatsby/pull/14889

We've deployed the PR to gatsbyjs.org for the last ~4-5 days and things are looking really good! There's been no new "missing resources" events since the deploy.

https://github.com/gatsbyjs/gatsby/pull/14889#issuecomment-505872897

@wardpeet is working on some tests to simulate network problems but we should have this out in the next 24 hours.

Thank you @KyleAMathews can't wait to get this running!

@KyleAMathews thanks to you and your team for that update!

@KyleAMathews I'm having this issue still occurring on my site. locally it works fine and in prod it doesn't. Also, I'm seeing it 100% of the time, not sporadically like some of the comments above. That said, I've looked through most of the solutions and utilizing them hasn't resulted in a fix. Do you have a specific version of Gatsby that has the fix in it so I can ensure that I'm hitting something different?

I'm willing to share URL privately as well as add contrib access to the private repo if someone from the gatsby team wants to take a look (DM me on twitter). Thanks for any tips/suggestions - to be clear the things I've tested are:

• Adding service worker reload on gatsby-browser.js
• Removing offline plugin
• Updating all node modules
• Ensuring that the imports are not referenced using .

We should have this one fixed in the latest gatsby release [email protected]. We have ran it on gatsbyjs.org and the errors dissapeared for us.

Please upgrade and let us know if there's any more trouble! Closing this for now.

@KyleAMathews Thanks - I did, unfortunately this didn't fix it although I think it's something else as the Missing Resources error went away but the primary issue is still there so I filed issue #15322

@KyleAMathews Thanks - I did, unfortunately this didn't fix it although I think it's something else as the Missing Resources error went away but the primary issue is still there so I filed issue #15322

We won't get Missing Resources because it was deleted and replaced with a different error: https://github.com/gatsbyjs/gatsby/pull/14889/files#diff-3182dbe2979ea0744c50242668edc572L173

We recently deployed this fix, going to check out bug logs for new/different errors.

EDIT: yeah looks like this.loadPageDataJson(...).then(...).finally is not a function is the new missing resources

@jackhair what browser are you testing on? I'm pretty sure we added a finally polyfill. Might be wrong though.

mind sharing your repo? or a small reproduction?

@jackhair what browser are you testing on? I'm pretty sure we added a finally polyfill. Might be wrong though.

mind sharing your repo? or a small reproduction?

We're seeing this across several browsers in production:

Do you mind sharing your website url so I can have a look and maybe debug it a bit?

Do you mind sharing your website url so I can have a look and maybe debug it a bit?

Sure! https://ritual.com

@jackhair I can confirm the bug. Could you make a new issue with the info provided above?

@wardpeet @jackhair we're also getting this finally polyfill issue, is there a new issue added? can it ref this one please?

@eknowles @wardpeet Sorry not had time to write a bug ticket for this yet. If you have a spare moment and want to create one, I can back it up with my own data too.

@wardpeet @jackhair I managed to track down our issue with the finally polyfill.

We found one of our dependencies was including babel-polyfill with useBuiltins: usage instead of entry.

Either way we had to downgrade redux-api-middleware (not related to gatbsy).
https://github.com/agraboso/redux-api-middleware/compare/v2.3.0...v3.0.0

this solved our finally bug. I would recommend following the stack trace up the chain and see which lib is the culprit as the Promise polyfill might be getting overridden but a nasty lib.

Thanks, we've seen this before with node_modules and babel-runtime. I'll have to rethink on how we can fix this in the future or at least give a proper error message.