StaticQuery failed after case sensitive file name change

[silkstudio]

Description

Have seen this issue being reported a couple of times before and have scoured the previous bug reports for suggestions with no avail.

From what seems like out of nowhere, useStaticQuery hooks that were working fine are now causing the site to break when in development mode.

When I run yarn develop the process runs smoothly and returns all green before prompting me to go to localhost/8000, however when I do I get the error 'Error: The result of this StaticQuery could not be fetched.'

Steps I've already tried:

1. run gatsby clean
2. remove node_modules folder and yarn.lock before then running yarn install
3. run yarn upgrade to make sure everything is up to date
4. git reset to a previous commit and try running yarn develop from there (still produces the same result)

Steps to reproduce

Recreating this issue is a little tricky as it's appeared in the site I'm working on which has 279 files so I was curious to see whether this was a known issue or one that anyone else had been experiencing. I can look into it if there's no other option.

Interestingly, when throwing together a codesandbox with the gatsby-default-starter the queries that are already present seem to work in it... so it's potentially an issue on my end?

Expected result

Hook should return static queries from graphql.

Actual result

Receive the error:

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

Along with the console output:

gatsby-browser-entry.js:77 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 useStaticQuery (gatsby-browser-entry.js:77)
at Header (Header.tsx:32)
at renderWithHooks (react-dom.development.js:14804)
at mountIndeterminateComponent (react-dom.development.js:17483)
at beginWork (react-dom.development.js:18597)
at HTMLUnknownElement.callCallback (react-dom.development.js:189)
at Object.invokeGuardedCallbackDev (react-dom.development.js:238)
at invokeGuardedCallback (react-dom.development.js:293)
at beginWork$1 (react-dom.development.js:23204)
at performUnitOfWork (react-dom.development.js:22158)
at workLoopSync (react-dom.development.js:22131)
at performSyncWorkOnRoot (react-dom.development.js:21757)
at scheduleUpdateOnFiber (react-dom.development.js:21189)
at updateContainer (react-dom.development.js:24374)
at react-dom.development.js:24759
at unbatchedUpdates (react-dom.development.js:21904)
at legacyRenderSubtreeIntoContainer (react-dom.development.js:24758)
at render (react-dom.development.js:24841)
at app.js:115

Environment

System:
OS: macOS 10.15.6
CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 12.18.3 - /usr/local/bin/node
Yarn: 1.22.5 - ~/.yarn/bin/yarn
npm: 6.14.8 - /usr/local/bin/npm
Languages:
Python: 2.7.16 - /usr/bin/python
Browsers:
Chrome: 86.0.4240.80
Firefox: 79.0
Safari: 13.1.2
npmPackages:
gatsby: ^2.24.41 => 2.24.82
gatsby-cli: ^2.12.92 => 2.12.110
gatsby-image: ^2.4.15 => 2.4.21
gatsby-plugin-manifest: ^2.4.22 => 2.4.35
gatsby-plugin-offline: ^3.2.23 => 3.2.34
gatsby-plugin-react-helmet: ^3.3.10 => 3.3.14
gatsby-plugin-sass: ^2.3.17 => 2.3.18
gatsby-plugin-sharp: ^2.6.26 => 2.6.43
gatsby-plugin-typescript: ^2.4.22 => 2.4.22
gatsby-source-filesystem: ^2.3.24 => 2.3.35
gatsby-source-sanity: ^6.0.3 => 6.0.4
gatsby-transformer-sharp: ^2.5.12 => 2.5.18
npmGlobalPackages:
gatsby-cli: 2.12.110

[claygiffin]

@silkstudio Did you by chance change the case of any of the default component files? I think that is what was giving me this same error. See #26563

[pvdz]

@silkstudio considering the site is relatively small, could you maybe create a minimal test case with one page where this problem persists for you? That way we can have a look as it's quite hard to tell anything right now :) Thanks!

[silkstudio]

@silkstudio Did you by chance change the case of any of the default component files? I think that is what was giving me this same error. See #26563

@claygiffin interestingly enough I had done that! However, even following the steps you mentioned didn't seem to sort it...

From what I can deduce so far, the issues are coming from two components, header.tsx and footer.tsx, both of which are running staticQuery hooks to query data from Sanity Studio (hence why the reproduction of the issue is a little complicated).

A couple of things to note about this:

1. When gatsby queries data internally such as in the seo.tsx component it works fine.
2. Similarly, when blog or project pages are being built with gatsby develop they use external page queries ("export const query = graphql", outsite the component) which queries Sanity data, again with no problems.
3. Using GraphiQl @ localhost:8000/___graphiql all works fine and all data (both internally and from sanity) can be queried and returns fine

@pvdz thanks for looking at this - due to the intergration with Sanity Studio, what's the best way to set up a minimal reproduction of this?

[silkstudio]

@silkstudio Did you by chance change the case of any of the default component files? I think that is what was giving me this same error. See #26563

@claygiffin interestingly enough I had done that! However, even following the steps you mentioned didn't seem to sort it...

From what I can deduce so far, the issues are coming from two components, header.tsx and footer.tsx, both of which are running staticQuery hooks to query data from Sanity Studio (hence why the reproduction of the issue is a little complicated).

A couple of things to note about this:

1. When gatsby queries data internally such as in the seo.tsx component it works fine.
2. Similarly, when blog or project pages are being built with gatsby develop they use external page queries ("export const query = graphql", outsite the component) which queries Sanity data, again with no problems.
3. Using GraphiQl @ localhost:8000/___graphiql all works fine and all data (both internally and from sanity) can be queried and returns fine

@pvdz thanks for looking at this - due to the intergration with Sanity Studio, what's the best way to set up a minimal reproduction of this?

@claygiffin Looks like you had the right idea after all!

After a little more digging it turned out that the issue was with the two aforementioned components and the cases of them.

The index.tsx files within each folder were exporting the default component from a capitalised version of the component path, for example:

HeaderComponent
|— header.tsx
|— index.tsx (contains: export { default } from './Header', should be './header')
|— _header.scss

Once this was changed we were good as new! Thanks for both you help with this.

[pvdz]

Happy you found a solution. I've updated the title so it may help other people to find this issue.