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

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.

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

As many people have noticed, getting the case wrong on import names can cause this problem if you’re on OSX as Gatsby is case insensitive when setting up static queries but OSX isn’t so if you have import foo from "./foo but the file is actually Foo.js — it’ll seem to work except for the static query failing.

An easy way to find where there’s this problem in your code base is by adding this plugin — https://github.com/Urthen/case-sensitive-paths-webpack-plugin — as it enforces strict case sensitivity.

You can add it by:

npm install case-sensitive-paths-webpack-plugin

Then in your gatsby-node.js file, modify the webpack config to add the plugin:

var CaseSensitivePathsPlugin = require('case-sensitive-paths-webpack-plugin');

exports.onCreateWebpackConfig = ({ actions, stage }) => {
  if (stage === "develop" || stage === "build-javascript") {
    actions.setWebpackConfig({
      plugins: [new CaseSensitivePathsPlugin()],
    });
  }
};

It’ll then print errors to your terminal that look like the following:

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?

any news on that? 😭

I am now encountering this issue in different ways:

• When using StaticQuery I geht this issue: https://github.com/gatsbyjs/gatsby/issues/26038, meaning: Instead of the component, Loading (StaticQuery) is shown.
• When using useStaticQuery the entire app blows up, returning 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

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?

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.

Just trying to follow along with the tutorial and I’m stuck on this Unhandled Runtime Error. It does not occur on the Gatsby Cloud hosted version, however, it does occur locally. Tried incognito, doesn’t work. Tried clean, clearing browser cache, reinstalling packages, scouring the code (most of it is copy pasted from the tutorial), nothing works.

It started when I added {mdx.frontmatter__slug}.js in part 6 of the tutorial to generate page templates. Instead I get ‘Error in function useStaticQuery in ./.cache/static-query.js:83’

I’m really stumped, by the tutorial. Wow.

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 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 assumed it was caching headers or the platform not purging but it seems like we should add a hash to the file

https://github.com/jsg2021/gatsby-staticquery-error-repro this is my min reproduction… in gatsby 2 it’s fine.

Ah, mixing gatsby-plugin-mdx and gatsby-plugin-feed trigger this

This error seems to happen to so many people, for completely different reasons. Isn’t it possible to send more information along with this error, so we have the smallest chance to find what’s going on?

The query could not be fetched: XYZ did not work would solve so many issues.

We’ve been seeing this error on all the versions of gatsby we’ve tried, we tried a ton of fixes suggested here and in the dozens of other issues with this error, and nothing ever worked. From v2.20 to today’s 3.10 in my history.

In my case, I used useStaticQuery in html.js file and it crashed in production build only. Worked just fine in dev mode.

Changing useStaticQuery to StaticQuery fixes the issue!

UPDATE: well, it doesn’t work. There is “Loading (StaticQuery)” inside a div on the page.

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

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

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!

Facing the same issue.

gatsby version 2.24.53

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

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