GraphQL fails after changing slug type from string to slug in Sanity

I can help you with this! The issue you're experiencing is a common one when changing from a string type to a slug type in Sanity. The problem is that in GraphQL, when a field is a slug type, it becomes an object with subfields (specifically slug.current), not a plain string.

The Core Issue

When you query a slug field in GraphQL, you need to access the current property because Sanity's slug type is an object with this structure:

{
  "_type": "slug",
  "current": "your-slug-value"
}

How to Fix Your Gatsby Queries

You need to update your GraphQL queries in Gatsby. Change from:

{
  allSanityYourType {
    nodes {
      slug  // This won't work anymore
    }
  }
}

To:

{
  allSanityYourType {
    nodes {
      slug {
        current  // Access the current property
      }
    }
  }
}

About sanity graphql deploy

Yes, running sanity graphql deploy again is definitely necessary! This is a crucial step that many developers miss. According to the Sanity documentation, every time you update your Sanity schema (not just the content), you need to re-deploy the GraphQL API for the changes to be reflected.

Steps to Resolve:

1. Run sanity graphql deploy from your studio folder to update the GraphQL schema
2. Update all your Gatsby GraphQL queries to access slug.current instead of just slug
3. If you're using the slug value in your code, update those references too (e.g., node.slug becomes node.slug.current)
4. Restart your Gatsby development server

Note About Gatsby Integration

The gatsby-source-sanity plugin works by first fetching the GraphQL Schema Definitions from Sanity's deployed GraphQL API, which is why redeploying is essential. Without redeploying, Gatsby is still working with the old schema definition where slug was a string.

Running sanity deploy (for your Studio) is separate from sanity graphql deploy and won't update your GraphQL schema, so make sure you've run the GraphQL-specific deploy command.