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

Created on 20 Aug 2020  ·  39Comments  ·  Source: gatsbyjs/gatsby

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

StaticQuery bug

Most helpful comment

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

All 39 comments

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?

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

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

Facing the same issue.

gatsby version 2.24.53

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

@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 [email protected]

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/

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

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

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

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

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

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.

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.

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

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

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

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.

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

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

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

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

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.

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

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

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.

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

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

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

any news on that? 😭

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

same problem
any new to solve it?

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.

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:

  • Maybe changing the offline strategy from StaleWhileRevalidate to NetworkFirst?
  • Or maybe the Gatsby cache loader logic fetching the chunks is wrong somewhere?
  • Another possibility is that I'm completely off-road and the right thing to do is check the cache-related headers of the JSON files, as suggested here, but I tried it with npx check-gatsby-caching and it's all green.

If someone has some ideas please get in touch!

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

  • update all dependencies to the latest version
  • delete node_modules, .cache
  • check for casing errors
  • fresh checkout in a different folder, just to be sure..

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

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 🤷‍♀️

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

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

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

3CordGuy picture 3CordGuy  ·  3Comments

benstr picture benstr  ·  3Comments

totsteps picture totsteps  ·  3Comments

brandonmp picture brandonmp  ·  3Comments

hobochild picture hobochild  ·  3Comments