Cannot query field on type error - Gatsby/Sanity integration issue

8 replies
Last updated: Dec 8, 2021
Cannot query field [field] on type [type]
. Bumping this in hopes to get some help, several of us are dead in the water. I'm struggling to figure out if this is related to
gatsby
or
gatsby-source-sanity
or
sanity
.

https://sanity-io-land.slack.com/archives/C9Z7RC3V1/p1638291184045400
AI Update

Based on the Slack thread context and this being a Gatsby-specific GraphQL error, this is almost certainly a schema synchronization issue between Sanity and Gatsby. Here's how to fix it:

The Root Cause

The "Cannot query field [field] on type [type]" error in Gatsby with gatsby-source-sanity happens when Gatsby's GraphQL schema doesn't match your current Sanity schema. This typically occurs when:

  1. You've updated your Sanity schema but haven't redeployed the GraphQL API
  2. Gatsby has cached an old version of your schema
  3. The GraphQL API deployment failed or is incomplete

Solutions to Try (in order)

1. Redeploy Your Sanity GraphQL API

Every time you update your Sanity schema, you need to redeploy the GraphQL API. From your Sanity Studio folder, run:

sanity graphql deploy

This is the most common fix - the GraphQL endpoint doesn't automatically update when you change your schema.

2. Clear Gatsby's Cache

After redeploying, clear Gatsby's cache to force it to fetch the new schema:

gatsby clean
gatsby develop

This removes the .cache and public folders and forces Gatsby to rebuild everything from scratch.

3. Verify Your gatsby-config.js

Make sure your gatsby-source-sanity plugin configuration is correct:

{
  resolve: 'gatsby-source-sanity',
  options: {
    projectId: 'your-project-id',
    dataset: 'your-dataset',
    // If using drafts or private datasets:
    token: process.env.SANITY_READ_TOKEN,
    watchMode: true, // for development
    overlayDrafts: true, // if previewing drafts
  }
}

4. Check for Field Name Mismatches

The error message should tell you which field is problematic. Verify that:

  • The field exists in your Sanity schema
  • The field name in your GraphQL query matches exactly (case-sensitive)
  • If querying _raw fields (like _rawBody), these are special Gatsby-specific fields that only work with gatsby-source-sanity, not in Sanity's GraphQL playground

Why This Happens

The gatsby-source-sanity plugin works by fetching GraphQL Schema Definitions from Sanity's deployed GraphQL API. If that deployed schema is out of sync with your actual schema or with what Gatsby has cached, you'll get field query errors.

If you're still stuck after trying these steps, share the specific field name and type from your error message for more targeted troubleshooting!

Show original thread
8 replies
user B
Could this be caused by
gatsby-source-sanity
? I don't see how this could be a graphql issue since
gatsby build
works but
gatsby develop
is failing. It's as if the local graphql instance is missing some fields from the Sanity schema.
I've tested with the last few versions up to
"gatsby-source-sanity": "^7.3.0-previews.3"


https://jmp.sh/gdSuKPM
Another data point, my deployed GraphQL Schema seems in good order (has the right fields) whereas the local schema seems to be missing fields (hence the error).
https://jmp.sh/0lwgIMK
I'll circle back to this tomorrow - in the meantime perhaps could you use
7.2.0
to unblock your work? Also, did you get a chance to try
7.3.0
instead of the
-previews
versions?
Thanks for being so thorough and active in your reports, User!
Thanks
user B
. So that is one of the baffling things about this issue, I did revert to
7.2.0
but the problem persisted (even cleared NPM). This is one of the things that's making is hard to know where the root cause lies. LMK if there is any other info I can provide to help trouble shoot. I appreciate your help.
user B
I apologize for the red herring but I figured out my issue and it was a misconfiguration on my end. As part of the Gatsby v4/Preview/gatsby-source-sanity update, I switched to using a
client-config.js
file and it was referencing the wrong env var which caused it to use the wrong sanity dataset.
You can ignore this issue.
No need to apologize! We should've had a better debugging experience for you to ensure you find misconfiguration before it hits you on the foot like that.
Do you think proactively logging the plugin configuration at the start
gatsby develop
could help, or would it just add more noise to the console?
I appreciate the extreme ownership
user B
but I think this one is just on me. I actually use to console lot out my current env and coincidentally I removed that along with this change because I felt I hadn't used it enough which was a dumb thing for me to do. Thanks for your time.
I appreciate the extreme ownership
user B
but I think this one is just on me. I actually use to console lot out my current env and coincidentally I removed that along with this change because I felt I hadn't used it enough which was a dumb thing for me to do. Thanks for your time.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?