search

gatsbyjs / gatsby

The best React-based framework with performance, scalability and security built in.
https://www.gatsbyjs.com
MIT License
55.27k stars 10.31k forks source link

Uncaught Error: The result of this StaticQuery could not be fetched. #26563

Closed jack0wsky closed 2 years ago

jack0wsky commented 4 years ago

Description

I have deployed site through Vercel and I'm facing following error. 

Uncaught Error: The result of this StaticQuery could not be fetched.

This is likely a bug in Gatsby and if refreshing the page does not fix it, please open an issue in https://github.com/gatsbyjs/gatsby/issues
    at h (gatsby-browser-entry.js:77)
    at e.default (products.js:15)
    at Ki (react-dom.production.min.js:153)
    at Fa (react-dom.production.min.js:175)
    at vo (react-dom.production.min.js:263)
    at cu (react-dom.production.min.js:246)
    at ou (react-dom.production.min.js:246)
    at Zo (react-dom.production.min.js:239)
    at react-dom.production.min.js:123
    at KqkS.t.unstable_runWithPriority (scheduler.production.min.js:19)

Error shows when I click on Products page or even Contact page where isn't static query declared. This error didn't exist while developing. Here's products.js file:

import { useStaticQuery, graphql } from 'gatsby'
import Product from '../components/product/product'

const Products = () => {
  const {
    allShopifyProduct: { edges },
  } = useStaticQuery(graphql`
    query Products {
      allShopifyProduct {
        edges {
          node {
            title
            productType
            shopifyId
            handle
            images {
              id
              localFile {
                childImageSharp {
                  fluid {
                    srcWebp
                    tracedSVG
                    base64
                    srcSetWebp
                  }
                  fixed {
                    src
                  }
                }
              }
            }
            variants {
              sku
              price
              title
              shopifyId
            }
          }
        }
      }
    }
  `)
  return (
    <Wrapper>
      <ProductsGrid>
        {edges.map(({ node }) => {
          return <Product key={node.shopifyId} product={node} />
        })}
      </ProductsGrid>
    </Wrapper>
  )
}

export default Products

I added query Products because I thought it'll help but it didn't.

Steps to reproduce

Expected result

website should work in production

Actual result

some problems with static query I guess

System: OS: macOS 10.15.6 CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz Shell: 5.7.1 - /bin/zsh Binaries: Node: 12.14.0 - /usr/local/bin/node Yarn: 1.22.4 - /usr/local/bin/yarn npm: 6.14.8 - /usr/local/bin/npm Languages: Python: 2.7.16 - /usr/bin/python Browsers: Chrome: 84.0.4147.125 Firefox: 79.0 Safari: 13.1.2 npmPackages: gatsby: ^2.17.4 => 2.24.10 gatsby-cli: ^2.12.62 => 2.12.65 gatsby-image: ^2.2.29 => 2.4.13 gatsby-plugin-google-analytics: ^2.0.13 => 2.3.13 gatsby-plugin-layout: ^1.0.11 => 1.3.10 gatsby-plugin-manifest: ^2.2.23 => 2.4.20 gatsby-plugin-offline: ^3.0.16 => 3.2.20 gatsby-plugin-react-helmet: ^3.1.13 => 3.3.10 gatsby-plugin-root-import: ^2.0.5 => 2.0.5 gatsby-plugin-sharp: ^2.2.32 => 2.6.21 gatsby-plugin-styled-components: ^3.3.10 => 3.3.10 gatsby-plugin-transition-link: ^1.20.2 => 1.20.2 gatsby-plugin-web-font-loader: ^1.0.4 => 1.0.4 gatsby-source-filesystem: ^2.1.33 => 2.3.22 gatsby-source-graphql: ^2.6.2 => 2.6.2 gatsby-source-shopify: ^3.2.24 => 3.2.24 gatsby-transformer-sharp: ^2.3.0 => 2.5.11 npmGlobalPackages: gatsby-cli: 2.12.87

pieh commented 4 years ago

Could you try updating gatsby and gatsby-plugin-offline to latest versions? There were couple of fixes related to static queries in those packages. If that doesn't help - could you share a link to your project (preferably) or to site deployed to Vercel so we could try debugging the runtime and see what's going wrong there?

jack0wsky commented 4 years ago

I guess I figured it out. For some reason the problem was in useStaticQuery hook. I switched to StaticQuery component and problem is solved.

barbalex commented 4 years ago

I just had the exact same error - ONLY ON PRODUCTION!

The error did not appear in dev.

I then realized that the only place I used a static query (via the useStaticQuery hook) could just as well accept a hardcoded value. After changing that the next update to production did not error any more. Phew!

I had updated the project just before. So all gatsby parts were up to date, see here: https://github.com/FNSKtZH/ae2/blob/5673e1d282e67e0c52ffff116e27c41d089e912e/package.json

Jaikant commented 4 years ago

Facing the same issue.

gatsby version 2.24.53

and I do not have gatsby-plugin-offline installed.

wardpeet commented 4 years ago

@jack0wsky @barbalex @Jaikant could you please create a reproduction for us or share your repository. We haven't been able to reproduce this issue. You can always sent me an email at ward@gatsbyjs.com

wardpeet commented 4 years ago

I've had a call with a customer and they were using cloudfront CDN. Everything was cached, please make sure you do not cache HTML, page-data folder! See https://www.gatsbyjs.com/docs/caching/

barbalex commented 4 years ago

Being a complete noob in these matters: Does https://vercel.com/docs/edge-network/caching mean that that happened in my case too?

wardpeet commented 4 years ago

@barbalex I'm not sure, if I believe their source code it should have the correct cache-control: https://github.com/vercel/vercel/blob/35fd7b5f9c628f9304cd9d2dcce9446ec4a2c1c7/packages/now-static-build/src/frameworks.ts#L72-L76

Perhaps it's something else, is it https://gabriel-software.ch? If so can you point me to a commit where it was broken? I could play with vercel and see if I can get to the same issue. (it might be offline plugin)

barbalex commented 4 years ago

@wardpeet It was this repository: https://github.com/FNSKtZH/ae2. If you check it out at commit 5673e1d282e67e0c52ffff116e27c41d089e912e you get the version that errored.

The repository is open source. Only the data in the postgresql database backing it up is not.

I just realized that this is the only one of my projects that I do not deploy via vercel (sorry for the noise!) but rather via the docker-compose.yml in the backend directory that is run in a docker droplet of digitalocean.com.

That docker backend uses caddy to serve the html folder. As I never spent any thought on caching and do not understand how that is done by caddy it is possible that it's caching was too aggressive. This may not have been a good idea but at the time I had just tried out building the backend via docker (migrating from more traditional, self configured droplets) and I simply gave this way to do it a shot. And it did work a few weeks before the incident and since.

wardpeet commented 4 years ago

well what this issue is showing is that we should make people more aware of caching and/or update static-query to contain a timestamp

einarpersson commented 4 years ago

I just got the same error message running Gatsby in production on Vercel: StaticQuery could not be fetched...

The latest commit was totally harmless, I just removed a file which was not referenced anywhere. And after doing another change to README.md it suddenly began to work in production.

This is super confusing for someone who is new to Gatsby

kbrock84 commented 4 years ago

I am currently getting this error. Initially I only noticed it after our build server pushed it to our staging environment. It took me forever, but I finally reproduced it locally with the following:

  1. go back to previous commit

  2. delete node_modules

  3. npm install

  4. Then I ran into a separate issue with babel so I ran npm upgrade gatsby which also upgraded the @babel dependencies.

  5. Finally gatsby build && gatsby serve

I was able to view the exact error locally, which is causing some of the data to not show on the page. It feels like a dependency issue.

kbrock84 commented 4 years ago

Ok, so building using gatsby build --no-uglify gave me an idea of where the error was coming from. Changed that form useStaticQuery to a StaticQuery component and the error went away.

The site looks great now EXCEPT there is a random "Loading (StaticQuery)" inside a div on the page. This has to be related, but at least it's not breaking anything now.

Again, this only happens on the production build.

claygiffin commented 4 years ago

I am running into this same issue. It happens with nearly every production build that I push to Netlify. I have not been able to reproduce the issue locally, and there are no build errors.

On my production site, the only solution I've found is to clear the cache and rebuild after each site update.

My current dependencies are:

"dependencies": {
    "babel-plugin-styled-components": "^1.11.1",
    "bowser": "^2.11.0",
    "gatsby": "^2.24.78",
    "gatsby-image": "^2.4.21",
    "gatsby-plugin-anchor-links": "^1.1.1",
    "gatsby-plugin-facebook-pixel": "^1.0.5",
    "gatsby-plugin-google-analytics": "^2.3.14",
    "gatsby-plugin-manifest": "^2.4.34",
    "gatsby-plugin-netlify": "^2.3.19",
    "gatsby-plugin-netlify-cache": "^1.2.0",
    "gatsby-plugin-react-helmet": "^3.3.14",
    "gatsby-plugin-react-svg": "^3.0.0",
    "gatsby-plugin-sharp": "^2.6.42",
    "gatsby-plugin-styled-components": "^3.3.14",
    "gatsby-source-filesystem": "^2.3.34",
    "gatsby-transformer-sharp": "^2.5.17",
    "google-map-react": "^2.1.8",
    "lodash": "^4.17.20",
    "modern-normalize": "^1.0.0",
    "polished": "^4.0.2",
    "prop-types": "^15.7.2",
    "react": "^16.14.0",
    "react-dom": "^16.14.0",
    "react-google-maps": "^9.4.5",
    "react-helmet": "^6.1.0",
    "react-icons": "^3.11.0",
    "react-intersection-observer": "^8.29.0",
    "react-merge-refs": "^1.1.0",
    "react-player": "^2.6.2",
    "react-portal": "^4.2.1",
    "react-spring": "^8.0.27",
    "styled-components": "^5.2.0"
  },
  "devDependencies": {
    "@types/styled-components": "^5.1.4",
    "prettier": "2.1.2"
  },
wardpeet commented 4 years ago

🤔 I assumed it was caching headers or the platform not purging but it seems like we should add a hash to the file

andreydrozd-smfe commented 4 years ago

I too am experiencing this issue and it's definitely not a cache issue for me. I too do not experience this issue locally.

I'm setting up a staging environment with no cache, just hosting the files on S3, and I am getting an undefined property error. It's like the query never ran. I empty the S3 bucket manually and redeploy, and the issue is still there.

My current dependencies are: 

"dependencies": {
    "@fortawesome/fontawesome-svg-core": "^1.2.22",
    "@fortawesome/free-brands-svg-icons": "^5.11.2",
    "@fortawesome/free-regular-svg-icons": "^5.11.2",
    "@fortawesome/free-solid-svg-icons": "^5.10.2",
    "@fortawesome/react-fontawesome": "^0.1.4",
    "@rhysforyou/gatsby-plugin-safari-site-icon": "^1.0.2",
    "@statuspage/status-widget": "^1.0.4",
    "babel-plugin-styled-components": "^1.10.6",
    "bootstrap": "^4.3.1",
    "crypto-browserify": "^3.12.0",
    "env-cmd": "^10.0.1",
    "gatsby": "^2.13.73",
    "gatsby-image": "^2.2.10",
    "gatsby-plugin-canonical-urls": "^2.1.18",
    "gatsby-plugin-facebook-pixel": "^1.0.3",
    "gatsby-plugin-favicon": "^3.1.6",
    "gatsby-plugin-google-analytics": "^2.1.23",
    "gatsby-plugin-lodash": "^3.1.8",
    "gatsby-plugin-manifest": "^2.2.6",
    "gatsby-plugin-offline": "^2.2.7",
    "gatsby-plugin-react-helmet": "^3.1.4",
    "gatsby-plugin-resolve-src": "^2.0.0",
    "gatsby-plugin-s3": "^0.3.2",
    "gatsby-plugin-sharp": "^2.2.13",
    "gatsby-plugin-sitemap": "^2.2.21",
    "gatsby-plugin-styled-components": "^3.1.11",
    "gatsby-plugin-web-font-loader": "^1.0.4",
    "gatsby-source-filesystem": "^2.1.11",
    "gatsby-source-prismic-graphql": "~3.4.0-beta.2",
    "gatsby-transformer-sharp": "^2.2.7",
    "js-cookie": "^2.2.1",
    "lodash": "^4.17.15",
    "memoize-one": "^5.1.1",
    "moment": "^2.24.0",
    "moment-timezone": "^0.5.27",
    "polished": "^3.4.1",
    "prismic-reactjs": "^1.0.1",
    "prop-types": "^15.7.2",
    "querystring": "^0.2.0",
    "react": "^16.9.0",
    "react-big-calendar": "^0.22.1",
    "react-cookie-consent": "^2.5.0",
    "react-dom": "^16.9.0",
    "react-helmet": "^5.2.1",
    "react-hooks-sse": "^1.0.0",
    "react-lazyload": "^2.6.5",
    "react-select": "^3.1.0",
    "react-slick": "^0.25.2",
    "react-string-replace": "^0.4.4",
    "react-super-responsive-table": "^5.1.1",
    "react-tooltip": "^3.11.1",
    "react-vis": "^1.11.7",
    "reactstrap": "^8.0.1",
    "slick-carousel": "^1.8.1",
    "smooth-scroll": "^16.1.0",
    "socket.io-client": "^2.3.0",
    "stickybits": "^3.7.1",
    "styled-components": "^4.3.2",
    "styled-tools": "^1.7.1",
    "whatwg-fetch": "^3.0.0"
  },
claygiffin commented 4 years ago

I may have figured out what the issue is. I haven't run into this error for my last few builds now after making this change.

When I set up my new Gatsby project, I changed the case of the default components (layout.js and seo.js) to be PascalCase (Layout.js, SEO.js). I know that git by default ignores changes in filename case, so I had to update my git.config to register these changes by running git config core.ignorecase false.

However, it appears that the original lowercase file was never completely removed. It didn't appear in my repository or local branch, but I noticed that when I staged my changes in VSCODE, both the lowercase and uppercase versions of the files were listed!

To fully remove the old versions of the files, I had to run:

git mv -f src/components/layout.js src/components/Layout.js &&
git mv -f src/components/seo.js src/components/SEO.js

Pushing that change seems to have fixed the Static Query error.

wardpeet commented 4 years ago

Oh I'll try to use this as a reproduction 👍 Thanks!

persocon commented 4 years ago

any news? I tried all the solutions, none works :/ and I can't update any staticquery on the company website because it breaks EVERYTHING

edit: <StaticQuery /> works but useStaticQuery doesn't and I have a bunch of places that I use the useStaticQuery :/

gerisztein commented 4 years ago

Same issue as @persocon ☝️

any news? I tried all the solutions, none works :/ and I can't update any staticquery on the company website because it breaks EVERYTHING

edit: <StaticQuery /> works but useStaticQuery doesn't and I have a bunch of places that I use the useStaticQuery :/

vincentleeuwen commented 4 years ago

Same issue as @persocon and @gerisztein ☝️

any news? I tried all the solutions, none works :/ and I can't update any staticquery on the company website because it breaks EVERYTHING edit: <StaticQuery /> works but useStaticQuery doesn't and I have a bunch of places that I use the useStaticQuery :/

Mehuge commented 4 years ago

I have a reproducible case, out of the box.

npm i -g gatsby-cli
gatsby new mywebsite
cd mywebsite
gatsby develop

Then browse to http://localhost:8000/

gives the error. See #27577 for details.

claygiffin commented 4 years ago

@Mehuge I was not able to reproduce the error locally following those steps.

kbrock84 commented 4 years ago

I resolved this error, though not in a desirable way.

I removed this from my gatsby-config.js

//gatsby-config.js
    siteMetadata: {
        title: `Site Title`,
        description: `Site Description`,
        author: `@siteauthor`,
    },

and just hard coded the values in the seo.js component and removed the graphql query.

//seo.js
const site = {
    siteMetadata: {
        title: `Site Title`,
        description: `Site Description`,
        author: `@siteauthor`,
    },
};

And now I no longer have the error.

Mehuge commented 4 years ago

@Mehuge I was not able to reproduce the error locally following those steps.

@claygiffin I have more info about my particular problem, and it is related to case. Having read you earlier comment about case of components, and having run gatsby develop from CMD prompt and it working, it turns out to be a cygwin case issue.

See, my projects are in D:\DEV but in cygwin I lazily cd /d/dev so there is a discrepancy in case in the root part of paths. I then noticed these warnings (amongst many similar warnings)

warn The plugin "dev-404-page" created a page with a component path that doesn't match the casing of the actual file. This may work locally, but will break on systems which are case-sensitive, e.g. most CI/CD
pipelines.

page.component:     "D:/dev/website/mywebsite/.cache/dev-404-page.js"
path in filesystem: "D:/DEV/website/mywebsite/.cache/dev-404-page.js"

and

warn There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* D:\DEV\website\mywebsite\node_modules\prop-types\checkPropTypes.js
    Used by 2 module(s), i. e.
    D:\DEV\website\mywebsite\node_modules\react\cjs\react.development.js
* D:\dev\website\mywebsite\node_modules\prop-types\checkPropTypes.js
    Used by 3 module(s), i. e.
    D:\dev\website\mywebsite\node_modules\react\cjs\react.development.js

and 

warn The GraphQL query in the non-page component "D:/dev/website/mywebsite/src/pages/using-typescript.tsx" will not be run.
Exported queries are only executed for Page components. It's possible you're
trying to create pages in your gatsby-node.js and that's failing for some
reason.

If the failing component(s) is a regular component and not intended to be a page
component, you generally want to use a <StaticQuery> (https://gatsbyjs.org/docs/static-query)
instead of exporting a page query.

If you're more experienced with GraphQL, you can also export GraphQL
fragments from components and compose the fragments in the Page component
query and pass data down into the child component — https://graphql.org/learn/queries/#fragments

I only took notice of the warnings after realising that when run from CMD prompt it doesn't generate any warnings.

If I cd /d/DEV/website/mywebsite then gatsby develop works.

bpod commented 4 years ago

Figured it out. For my issue anyway, but it seems as if other peoples issue may be stemming from the same kind of symptoms.

For me it was emotion-cache.

In a Netlify production build, it would fail the first time a page would load while using the useStaticQuery hook. If you would refresh, it would not reproduce the error.. so only on first load. This got me thinking it might have something to do with caching strategy. I removed my custom implementation of emotion-cache and now everything appears to be just fine.

This is a rather unique case, but hopefully it helps others narrow this down.

bpod commented 4 years ago

Figured it out. For my issue anyway, but it seems as if other peoples issue may be stemming from the same kind of symptoms.

For me it was emotion-cache.

In a Netlify production build, it would fail the first time a page would load while using the useStaticQuery hook. If you would refresh, it would not reproduce the error.. so only on first load. This got me thinking it might have something to do with caching strategy. I removed my custom implementation of emotion-cache and now everything appears to be just fine.

This is a rather unique case, but hopefully it helps others narrow this down.

I Lied... Still an issue. :(

claygiffin commented 4 years ago

@bpod At any point during your project did you change the case of any filenames?

bpod commented 4 years ago

@bpod At any point during your project did you change the case of any filenames?

Nope.. I thought of that too... but no, been consistent with that.

persocon commented 4 years ago

any news on that? 😭

honmanyau commented 4 years ago

I ran into the same issue earlier and it was a case error in the Importing component, but not the Imported component where the static query is made:

// index.js
import React from 'react';

import Header from '../components/Header'

// ...
// header.js
import React from 'react';
import { Link, graphql, useStaticQuery } from 'gatsby';

const Header = () => {
  const data = useStaticQuery(graphql`query {
    site {
      siteMetadata {
        title
      }
    }
  }`);

  // ...
};

export default Header;

Using the example above, the solution for me was to simply change the filename of the relevant import in index.js to match the filename of the imported component:

// index.js
import React from 'react';

import Header from '../components/header'

// ...

I initially attempted gatsby clean, removed node_modules and reinstalled them but that didn't work for me. Although I doubt that it was the problem to begin with, because after playing around for a while the only way I could cause the error to be thrown was unmatching cases between the import statement and the filename of the imported component.

Also not sure if it's worth mentioning, but might as well throw it out there: in .cache/gatsby-browser-entry.js, it appears that React.useContext(StaticQueryContext) returns an empty object when the aforementioned case mismatch exists, which is what lead to the error being thrown in the first place.

Note that this is just what happened in my particularly case, but I hope it helps!

Edit: I forgot to mention that I'm using macOS (10.15.7, case-insensitive).

observerzy commented 3 years ago

same problem any new to solve it?

caesarsol commented 3 years ago

For anyone hitting the Loading (StaticQuery) problem when using <StaticQuery> as described by @kbrock84, I found the solution in https://github.com/gatsbyjs/gatsby/issues/26038#issuecomment-664987789

It's not exactly a solution, but a workaround: you have to disable the offline support. Remove gatsby-plugin-offline and add gatsby-plugin-remove-serviceworker in the Gatsby plugins (you'll need to npm install that).

Edit: I think the error is the same as the The result of this StaticQuery could not be fetched, which is the same problem using the useStaticQuery hook instead of the <StaticQuery> component. So this should work also for anyone hitting the problem in object.

caesarsol commented 3 years ago

More information on my findings: the cause seems to be the StaleWhileRevalidate strategy in fetching page-data.json files: https://github.com/gatsbyjs/gatsby/blob/e4fd0ad8cda56996f42e0a2b9fd6b580823289c9/packages/gatsby-plugin-offline/src/gatsby-node.js#L144-L145

This makes every request to page-data.json return with an old version of the file, which contains the incorrect staticQueryHashes. If you compare the requests in the errored page and after a refresh, you'll see the content of the relative page-data.json will have different staticQueryHashes, being the latest correct.

This also explains the apparent random nature of the error: it happens only after a query changes, and the ServiceWorker in the browser still has the previous version cached.

I am unsure on the best solution when one wants to keep the offline cache functionality:

If someone has some ideas please get in touch!

timurc commented 3 years ago

@LekoArts asked my to add my reproduction. Here it is:

Steps to reproduce

I made a branch that at least at my machine reproduces the error: https://github.com/voellig-ohne/timobecker/tree/reproduce-issue

Clone into repo, checkout out reproduce-issue, npm i, npm start, open in browser

Things I tried:

My original issue: https://github.com/gatsbyjs/gatsby/issues/28537

persocon commented 3 years ago

im still having this issue and it only happens in prod 🤷 couldn't figure out yet how to solve, im just removing all the bullshit staticquery from it and it works 🤷‍♀️

caesarsol commented 3 years ago

@persocon I had the same exactly. Do you have gatsby-plugin-offline active?

persocon commented 3 years ago

@caesarsol yes I do have, did removing it solved for you?

caesarsol commented 3 years ago

@persocon yes it did, please read my messages above.

MarekMaras commented 3 years ago

I too am experiencing this issue it's not a cache issue for me. Locally it works. As soon as I deploy it to Netlify and open up my main domain, it shows this errors:

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

This is likely a bug in Gatsby and if refreshing the page does not fix it, please open an issue in https://github.com/gatsbyjs/gatsby/issues
    at m (app-932771afe1ec633c2149.js:2)
    at O (component---src-pages-index-js-7077fee428ff1b64d194.js:1)
    at Ki (framework-305b3707783ccc9d7ca6.js:2)
    at vo (framework-305b3707783ccc9d7ca6.js:2)
    at cu (framework-305b3707783ccc9d7ca6.js:2)
    at ou (framework-305b3707783ccc9d7ca6.js:2)
    at Zo (framework-305b3707783ccc9d7ca6.js:2)
    at qo (framework-305b3707783ccc9d7ca6.js:2)
    at Du (framework-305b3707783ccc9d7ca6.js:2)
    at framework-305b3707783ccc9d7ca6.js:2
Za @ framework-305b3707783ccc9d7ca6.js:2

vTools failed to load SourceMap: Could not load content for https://www.marek-maras.de/webpack-runtime-86bcfb54a9e4c0e2c403.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load SourceMap: Could not load content for https://www.marek-maras.de/app-932771afe1ec633c2149.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load SourceMap: Could not load content for https://www.marek-maras.de/framework-305b3707783ccc9d7ca6.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load SourceMap: Could not load content for https://www.marek-maras.de/4dbd8774c93329dba068f4828d4180636febe693-4865a04b1f4372fe8150.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load SourceMap: Could not load content for https://www.marek-maras.de/component---src-pages-index-js-7077fee428ff1b64d194.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load SourceMap: Could not load content for https://www.marek-maras.de/component---cache-caches-gatsby-plugin-offline-app-shell-js-ad6431e4664bcf916d19.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load SourceMap: Could not load content for https://www.marek-maras.de/cb1608f2-8597d708199ed60075bc.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

The Netlify Preview Deploy URL works like a charm so I guess, it's as soon as it switches to Production, those errors come up.

Running on NODE_VERSION = v12 on Netlify because of an bug/error in postcss for tailwind v2. Same occured on v15.4 and v15.5

`  "dependencies": {
    "@emotion/react": "^11.1.4",
    "@emotion/styled": "^11.0.0",
    "@fortawesome/fontawesome-svg-core": "^1.2.32",
    "@fortawesome/free-solid-svg-icons": "^5.15.1",
    "@fortawesome/react-fontawesome": "^0.1.14",
    "@sanity/block-content-to-react": "^2.0.7",
    "@tailwindcss/forms": "^0.2.1",
    "autoprefixer": "^10.1.0",
    "cross-env": "^7.0.3",
    "dotenv": "^8.2.0",
    "esm": "^3.2.25",
    "fontsource-muli": "^4.0.0",
    "gatsby": "^2.29.2",
    "gatsby-cli": "^2.16.2",
    "gatsby-image": "^2.8.0",
    "gatsby-link": "^2.8.0",
    "gatsby-plugin-cookiehub-banner": "^0.1.0",
    "gatsby-plugin-manifest": "^2.9.1",
    "gatsby-plugin-netlify": "^2.8.0",
    "gatsby-plugin-nprogress": "^2.7.0",
    "gatsby-plugin-offline": "^3.7.1",
    "gatsby-plugin-postcss": "^3.4.0",
    "gatsby-plugin-react-helmet": "^3.7.0",
    "gatsby-plugin-robots-txt": "^1.5.5",
    "gatsby-plugin-sharp": "^2.11.2",
    "gatsby-plugin-sitemap": "^2.9.0",
    "gatsby-plugin-styled-components": "^3.7.0",
    "gatsby-plugin-typography": "^2.9.0",
    "gatsby-source-filesystem": "^2.8.1",
    "gatsby-source-sanity": "^6.0.4",
    "gatsby-transformer-sharp": "^2.9.0",
    "install": "^0.13.0",
    "netlify-lambda": "^2.0.2",
    "npm": "^6.14.10",
    "polished": "^4.0.5",
    "postcss": "^8.2.1",
    "postcss-cli": "^8.3.1",
    "precss": "^4.0.0",
    "prop-types": "^15.7.2",
    "react": "^17.0.1",
    "react-cookie-consent": "^6.2.1",
    "react-dom": "^17.0.1",
    "react-helmet": "^6.1.0",
    "react-router-dom": "^5.2.0",
    "react-router-hash-link": "^2.3.1",
    "react-scroll": "^1.8.1",
    "react-typography": "^0.16.19",
    "styled-components": "^5.2.1",
    "tailwindcss": "^2.0.2",
    "twin.macro": "^2.0.7",
    "typography": "^0.16.19"
  },
  "devDependencies": {
    "@babel/plugin-proposal-decorators": "^7.12.12",
    "@emotion/babel-plugin-jsx-pragmatic": "^0.1.5",
    "@hot-loader/react-dom": "^17.0.1",
    "@tailwindcss/custom-forms": "0.2.1",
    "babel-eslint": "10.1.0",
    "cssnano": "4.1.10",
    "eslint": "7.16.0",
    "eslint-loader": "3.0.4",
    "eslint-plugin-import": "2.22.1",
    "eslint-plugin-react": "7.21.5",
    "gatsby-plugin-eslint": "2.0.8",
    "prettier": "2.2.1"
  },`
jm27 commented 3 years ago

Hi everyone, as suggested in another thread deleting the node_modules folder and reinstalling using npm install, fix this issue for me. I would like to know more about why it fix it? and what is causing the issue? Great product btw thanks!

esotericjules commented 3 years ago

I ran into the same issue earlier and it was a case error in the Importing component, but not the Imported component where the static query is made:

// index.js
import React from 'react';

import Header from '../components/Header'

// ...
// header.js
import React from 'react';
import { Link, graphql, useStaticQuery } from 'gatsby';

const Header = () => {
  const data = useStaticQuery(graphql`query {
    site {
      siteMetadata {
        title
      }
    }
  }`);

  // ...
};

export default Header;

Using the example above, the solution for me was to simply change the filename of the relevant import in index.js to match the filename of the imported component:

// index.js
import React from 'react';

import Header from '../components/header'

// ...

I initially attempted gatsby clean, removed node_modules and reinstalled them but that didn't work for me. Although I doubt that it was the problem to begin with, because after playing around for a while the only way I could cause the error to be thrown was unmatching cases between the import statement and the filename of the imported component.

Also not sure if it's worth mentioning, but might as well throw it out there: in .cache/gatsby-browser-entry.js, it appears that React.useContext(StaticQueryContext) returns an empty object when the aforementioned case mismatch exists, which is what lead to the error being thrown in the first place.

Note that this is just what happened in my particularly case, but I hope it helps!

Edit: I forgot to mention that I'm using macOS (10.15.7, case-insensitive).

This worked for me.

momosetti commented 3 years ago

I faced the same issue on Gatsby 2.31.1 and I downgrade it to 2.24.79 without using gatsby-plugin-offline, it works well.

lanzoninicola commented 3 years ago

The solution posted by @esotericjules works also for me.

When I imported the component containing the query with the same capitalisation as the file name, I no longer faced the problem.

HeroCarouselController.js // --> filename and the component that contains the query

I imported the above component inside another component:

import HeroCarouselController from "../../hero/heroCarouselController" // --> I faced the problem

import HeroCarouselController from "../../hero/HeroCarouselController" // --> It works, the filename and the reference to the filename have the same capitalization
barbalex commented 3 years ago

I am now encountering this issue in different ways:

This is the component: https://github.com/FNSKtZH/ae2/blob/master/src/components/Home.js

This happens only in production, so very bad 👿

PLEASE SOLVE THIS ISSUE

It has been around for ages and many have endured it. I somehow have a feeling that it might be related to https://github.com/gatsbyjs/gatsby/issues/19618, which has also hit very hard, myself included.

Sorry for being so explicit but Gatsby being so big, this should have been solved a long time ago.

Result of running gatsby info --clipboard:

  System:
    OS: Windows 10 10.0.19042
    CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
  Binaries:
    Node: 15.6.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 7.4.0 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.17
  Browsers:
    Chrome: 87.0.4280.141
    Edge: Spartan (44.19041.423.0), Chromium (88.0.705.50)
  npmPackages:
    gatsby: 2.31.1 => 2.31.1
    gatsby-cli: 2.18.0 => 2.18.0
    gatsby-image: ^2.10.0 => 2.10.0
    gatsby-plugin-create-client-paths: 2.9.0 => 2.9.0
    gatsby-plugin-eslint: 2.0.8 => 2.0.8
    gatsby-plugin-manifest: 2.11.0 => 2.11.0
    gatsby-plugin-offline: 3.9.0 => 3.9.0
    gatsby-plugin-react-helmet: 3.9.0 => 3.9.0
    gatsby-plugin-sharp: 2.8.0 => 2.8.0
    gatsby-plugin-styled-components: 3.9.0 => 3.9.0
    gatsby-plugin-typography: 2.11.0 => 2.11.0
    gatsby-remark-autolink-headers: 2.10.0 => 2.10.0
    gatsby-remark-copy-linked-files: 2.9.0 => 2.9.0
    gatsby-remark-emojis: 0.4.3 => 0.4.3
    gatsby-remark-external-links: 0.0.4 => 0.0.4
    gatsby-remark-images: 3.10.0 => 3.10.0
    gatsby-remark-images-medium-zoom: 1.7.0 => 1.7.0
    gatsby-source-filesystem: 2.10.0 => 2.10.0
    gatsby-transformer-remark: 2.15.0 => 2.15.0
    gatsby-transformer-sharp: 2.11.0 => 2.11.0
  npmGlobalPackages:
    gatsby: 2.30.1

The app is served using caddy v2.3.0 on docker: https://github.com/FNSKtZH/ae2/blob/master/backend/caddy/Caddyfile

Also, this appears when checking the caching:

root@pca:/mnt/c/Users/alexa# npx check-gatsby-caching https://artdaten.ch
npx: installed 230 in 15.942s
Validating headers for the Gatsby site: https://artdaten.ch

HTML
https://artdaten.ch
❌ - Expected
+ Received

  Object {
-   "null": "No cache-control header set",
+   "max-age": 0,
+   "must-revalidate": true,
+   "public": true,
  }

app-data.json
https://artdaten.ch/page-data/app-data.json
❌ - Expected
+ Received

  Object {
-   "null": "No cache-control header set",
+   "max-age": 0,
+   "must-revalidate": true,
+   "public": true,
  }

Page Data
https://artdaten.ch/page-data\index\page-data.json
❌ - Expected
+ Received

  Object {
-   "null": "No cache-control header set",
+   "max-age": 0,
+   "must-revalidate": true,
+   "public": true,
  }

JavaScript and CSS
https://artdaten.ch/webpack-runtime-2748cbf525d8b5a1785d.js
❌ - Expected
+ Received

  Object {
-   "null": "No cache-control header set",
+   "immutable": true,
+   "max-age": 31536000,
+   "public": true,
  }

To be honest, I have no idea what it means and if necessary, how to change. Especially as this list makes it seem like some things are set up wrong while the docs (https://www.gatsbyjs.com/docs/caching/#page-data) show for instance for page-data that exactly what I seem to have set is right, although this list makes it seem to be wrong???? The expected value is not what the docs say is needed.

Concerning https://github.com/gatsbyjs/gatsby/issues/26563#issuecomment-704702783

@wardpeet says:

we should make people more aware of caching

Gatsby is supposed to create a static site. That's one of the things that make it interesting for many. If you have to get a doctorate in setting headers for files served that kind of destroys the point.

we should ... update static-query to contain a timestamp

Why don't you do that? Would that solve our issues?

hsaenz commented 3 years ago

So, where we are with this? I made sure to:

Nothing solved the issue and it would be real sad just to move away all my code from the hooks version.

This happens to me specifically by fetching images, it seems that the traced svg version from "GatsbyImageSharpFluid_tracedSVG" gets stuck at some point.

Also wondering if it has something to do with cache handling, as this will never happen to me when doing a hard reaload.

Have a site example I can publish if someone wants to make an active debugging, right now I ended up migrating everything to page queries since my client need to see the pre-prod build, that fixed the issues.

llamerr commented 3 years ago

Same problem. After replacing useStaticQuery with <StaticQuery /> it started working for me. Removing node_modules and package-lock.json did not help.

endymion1818 commented 3 years ago

Could be related to https://github.com/gatsbyjs/gatsby/issues/29416

endymion1818 commented 3 years ago

I've seen this bug too, not running locally but in production. In the pipeline it was built with Gatsby v2.30

  System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.19.0 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.0.3 - /usr/local/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 88.0.4324.150
    Edge: 88.0.705.63
    Firefox: 85.0.1
    Safari: 14.0.2
  npmPackages:
    gatsby: ^2.1.20 => 2.25.0
    gatsby-image: ^2.5.0 => 2.9.0
    gatsby-plugin-google-analytics: ^2.1.29 => 2.9.0
    gatsby-plugin-google-tagmanager: ^2.1.18 => 2.9.0
    gatsby-plugin-mdx: ^1.2.15 => 1.8.0
    gatsby-plugin-polyfill-io: ^1.1.0 => 1.1.0
    gatsby-plugin-react-helmet: ^3.1.10 => 3.8.0
    gatsby-plugin-react-helmet-canonical-urls: ^1.2.0 => 1.4.0
    gatsby-plugin-remove-serviceworker: ^1.0.0 => 1.0.0
    gatsby-plugin-remove-trailing-slashes: ^2.2.1 => 2.8.0
    gatsby-plugin-robots-txt: ^1.3.0 => 1.5.5
    gatsby-plugin-sharp: ^2.3.4 => 2.12.0
    gatsby-plugin-sitemap: ^2.0.1 => 2.10.0
    gatsby-plugin-styled-components: ^3.0.0 => 3.8.0
    gatsby-plugin-typescript: ^2.0.3 => 2.10.0
    gatsby-source-apiserver: 2.1.5 => 2.1.5
    gatsby-source-datocms: ^2.4.0 => 2.5.7
    gatsby-source-filesystem: ^2.0.1 => 2.9.0
    gatsby-transformer-javascript-frontmatter: ^2.0.0 => 2.8.0
    gatsby-transformer-sharp: ^2.3.6 => 2.10.0
  npmGlobalPackages:
    gatsby-cli: 2.19.1
llamerr commented 3 years ago

Same problem. After replacing useStaticQuery with <StaticQuery /> it started working for me. Removing node_modules and package-lock.json did not help.

In my case problem did not occur during develop, and only happened upon build. In all other cases of useStaticQuery everything worked fine. Difference from other cases was that query itself was imported from another file.