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

Created on 16 Sep 2020  Â·  10Comments  Â·  Source: gatsbyjs/gatsby

Description

I have 1 page and 1 component that is imported to that page. The issue happens when a component that uses a graphql query is imported and rendered (like I am showing bellow). But if I add the same query to the page, without importing the component, all works

Steps to reproduce

In gatsby-config.js I have
module.exports = { siteMetadata: { title: "My cool site", name: "Alex" }, plugins: [ 'gatsby-plugin-sass' ], }

My component I have

import React from "react"
import { Link, graphql, useStaticQuery } from "gatsby"

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

  return (
      <h1>
          {data.site.siteMetadata.title}
      </h1>
  )
}

export default Header

My page

import React from 'react'
import Header from '../components/header'

export default function IndexPage() {
  return (
    <div>
        <Header />
    </div>
  )
}

Expected result

Get the title

Actual result

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

**useStaticQuery**
/Volumes/LaCie/Project/sandbox/gatsbyjs/gatsby-bootcamp/.cache/gatsby-browser-entry.js:77
  74 | if (context?.[query]?.data) {
  75 |   return context[query].data
  76 | } else {
> 77 |   throw new Error(
  78 |     `The result of this StaticQuery could not be fetched.\n\n` +
  79 |       `This is likely a bug in Gatsby and if refreshing the page does not fix it, ` +
  80 |       `please open an issue in https://github.com/gatsbyjs/gatsby/issues`

Header


src/components/header.js:7
   4 | import headerStyles from "./header.module.scss"
   5 | 
   6 | const Header = () => {
>  7 |   const data = useStaticQuery(graphql`
   8 |     query {
   9 |       site {
  10 |         siteMetadata {

â–¶ 16 stack frames were collapsed.
(anonymous function)
/Volumes/LaCie/Project/sandbox/gatsbyjs/gatsby-bootcamp/.cache/app.js:103
  100 | const preferDefault = m => (m && m.default) || m
  101 | let Root = preferDefault(require(`./root`))
  102 | domReady(() => {
> 103 |   renderer(<Root />, rootElement, () => {
  104 |     apiRunner(`onInitialClientRender`)
  105 |   })
  106 | })

Environment

System:
OS: macOS 10.15.2
CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Shell: 5.0.11 - /usr/local/bin/bash
Binaries:
Node: 10.15.3 - /usr/local/bin/node
npm: 6.4.1 - /usr/local/bin/npm
Languages:
Python: 2.7.16 - /usr/bin/python
Browsers:
Chrome: 85.0.4183.102
Safari: 13.0.4
npmPackages:
gatsby: ^2.24.54 => 2.24.60
gatsby-plugin-sass: ^2.3.13 => 2.3.13
npmGlobalPackages:
gatsby-cli: 2.12.97

What I tried

I deleted cache, modules, reinstalled, updated.

needs reproduction bug

All 10 comments

I have been using Gatsby successfully for the past several months with no problems. Just 30 minutes ago, while fetching a stable graphQL query used a million times before, I have got exactly the same message: "Error: The result of this StaticQuery could not be fetched"

To me it is happening as I use a customHook (derived from the stable graphQL query mentioned above) to recycle the same data across components and use it to run some logic independent from individual components.

Will watch this conversation and provide further info on my case if needed.

I found the issue. This happens when a component that uses a graphql query is imported and rendered (like I showed in the issue description above). But if I add the same query to the page, without importing the component, all works

import React from 'react'
import { useStaticQuery, graphql } from "gatsby"

export default function IndexPage() {
  const data = useStaticQuery(graphql`
    query {
      site {
        siteMetadata {
          title
        }
      }
    }
  `)
  return (
    <div>
        <h3>{data.site.siteMetadata.title}</h3>
    </div>
  )
}

Thanks alextseitlin and useful.

I have found other documented issues here on GitHub where importing a graphQL query not exactly as it is documented can create issues. Useful link to known limitations here: https://www.gatsbyjs.com/docs/use-static-query/#known-limitations

For what is worth for other readers, I was importing from an independent file a customHook containing the useStaticQuery exactly as documented by Gatsby in the link above, but I was then consuming that customHook within a function returning a component, which (within the same file) was exported/rendered later as part of another second component (part of a react-bootstrap related infrastructure)

To fix the bug, I had to consume the customHook/graphQL imported query within one single component, then exported/rendered stand-alone.

@warpalatino I tried the oficial example https://www.gatsbyjs.com/docs/use-static-query/#basic-example and it also has the same issue

I'm having the same problems as well when using static query. I had to hit shift + command + r to make it work.

But I feel like it's gonna cause so much problem once we hit production cause we can't just ask the current users to clear the cache every single time we make an update.

We're not even using custom hooks, just the same pattern as the docs. We might have to avoid using StaticQuery's for now as a quickfix.

Hi!

Sorry to hear you're running into an issue. To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.

If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.

Thanks for using Gatsby! 💜

@daydream05 do you have proper caching headers in place?

There might be an issue there actually since I'm not entirely sure if I set up our headers correctly. I tried to base it off here

We use docker and here's our nginx config.

```.conf
location / {
if ($http_x_forwarded_proto = "http") {
return 301 https://$server_name$request_uri;
}

  root /usr/share/nginx/html;
  index index.html indx.htm;
}

location ~* \.(?:html)$ {
  if ($http_x_forwarded_proto = "http") {
    return 301 https://$server_name$request_uri;
  }

  root /usr/share/nginx/html;
  add_header Cache-Control "public, max-age=0, no-cache";
  expires    off;
}

location /page-data {
  add_header Cache-Control "public, max-age=0, must-revalidate";
}

location = /sw.js {
  add_header Cache-Control "public, max-age=0, must-revalidate";
}

location /static {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

location ~* \.(ico|jpg|jpeg|png|gif|svg|js|jsx|css|less|swf|eot|ttf|otf|woff|woff2|json)$ {
  if ($http_x_forwarded_proto = "http") {
    return 301 https://$server_name$request_uri;
  }

  root /usr/share/nginx/html;
  add_header Cache-Control "public";
  expires +1y;
}

```

Am I missing something? (Like the app-data.json maybe?)

Update:
The last location of this code was blocking the page-data.json

I think this error occurs if you're caching the page-data.json and your data changes.

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 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.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

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

I'm closing this, as it seems to be a duplicate of #26563.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mikestopcontinues picture mikestopcontinues  Â·  3Comments

totsteps picture totsteps  Â·  3Comments

theduke picture theduke  Â·  3Comments

timbrandin picture timbrandin  Â·  3Comments

signalwerk picture signalwerk  Â·  3Comments