Issue with GraphQL API deployment causing build failure

6 replies
Last updated: Apr 29, 2020
Hey, this is still my first day using sanity.io 🙂 After creating a project at one point I ran sanity upgrade, and now my build on web is failing with these errors: > sanity graphql deploy --playground10
:25:30 PM: Dataset: production10
:25:30 PM: Tag: default10
:25:32 PM: Found BREAKING changes from previous schema:10
:25:32 PM: - SiteSettings._id changed type from ID! to ID.10
:25:32 PM: - SiteSettings._type changed type from String! to String.10
:25:32 PM: - SiteSettings._createdAt changed type from DateTime! to DateTime.10
:25:32 PM: - SiteSettings._updatedAt changed type from DateTime! to DateTime.10
:25:32 PM: - SiteSettings._rev changed type from String! to String.10
:25:32 PM: - Document._id changed type from ID! to ID.10
:25:32 PM: - Document._type changed type from String! to String.10
:25:32 PM: - Document._createdAt changed type from DateTime! to DateTime.10
:25:32 PM: - Document._updatedAt changed type from DateTime! to DateTime.10
:25:32 PM: - Document._rev changed type from String! to String.10
:25:32 PM: - Author._id changed type from ID! to ID.10
:25:32 PM: - Author._type changed type from String! to String.10
:25:32 PM: - Author._createdAt changed type from DateTime! to DateTime.10
:25:32 PM: - Author._updatedAt changed type from DateTime! to DateTime.10
:25:32 PM: - Author._rev changed type from String! to String.10
:25:32 PM: - SanityImageAsset._id changed type from ID! to ID.10
:25:32 PM: - SanityImageAsset._type changed type from String! to String.10
:25:32 PM: - SanityImageAsset._createdAt changed type from DateTime! to DateTime.10
:25:32 PM: - SanityImageAsset._updatedAt changed type from DateTime! to DateTime.10
:25:32 PM: - SanityImageAsset._rev changed type from String! to String.10
:25:32 PM: - Post._id changed type from ID! to ID.10
:25:32 PM: - Post._type changed type from String! to String.10
:25:32 PM: - Post._createdAt changed type from DateTime! to DateTime.10
:25:32 PM: - Post._updatedAt changed type from DateTime! to DateTime.10
:25:32 PM: - Post._rev changed type from String! to String.10
:25:32 PM: - Category._id changed type from ID! to ID.10
:25:32 PM: - Category._type changed type from String! to String.10
:25:32 PM: - Category._createdAt changed type from DateTime! to DateTime.10
:25:32 PM: - Category._updatedAt changed type from DateTime! to DateTime.10
:25:32 PM: - Category._rev changed type from String! to String.10
:25:32 PM: - SanityFileAsset._id changed type from ID! to ID.10
:25:32 PM: - SanityFileAsset._type changed type from String! to String.10
:25:32 PM: - SanityFileAsset._createdAt changed type from DateTime! to DateTime.10
:25:32 PM: - SanityFileAsset._updatedAt changed type from DateTime! to DateTime.10
:25:32 PM: - SanityFileAsset._rev changed type from String! to String.10
:25:32 PM: ? Do you want to deploy a new API despite the dangerous changes? (y/N)10
:25:32 PM:10
:25:32 PM:10
:25:32 PM: npm10
:25:32 PM: ERR! code ELIFECYCLE10
:25:32 PM: npm ERR! errno 13010
:25:32 PM: npm10
:25:32 PM: ERR! sanity-gatsby-blog-studio@1.0.8 graphql-deploy:
sanity graphql deploy --playground
10
:25:32 PM: npm10
:25:32 PM: ERR!10
:25:32 PM: Exit status 13010
:25:32 PM: npm ERR!10
:25:32 PM: npm ERR!10
:25:32 PM: Failed at the sanity-gatsby-blog-studio@1.0.8 graphql-deploy script.10
:25:32 PM: npm ERR! This is probably not a problem with npm. There is likely additional logging output above.10
:25:32 PM: npm10
:25:32 PM: ERR! A complete log of this run can be found in:10
:25:32 PM: npm ERR! /opt/buildhome/.npm/_logs/2020-04-28T19_25_32_466Z-debug.log
AI Update

Welcome to Sanity! Don't worry, this is a common issue that's easy to fix.

The error you're seeing is because your build process is being blocked by an interactive prompt asking you to confirm "breaking changes" in your GraphQL schema. The changes aren't actually dangerous in your case—when you ran sanity upgrade, it updated your schema in a way that made some fields nullable (changed from ID! to ID, String! to String, etc.).

Since you're deploying in an automated environment (like Netlify or another CI/CD platform), the build process can't respond to interactive prompts, so it times out and fails.

The Solution

Use the --force flag to bypass the confirmation prompt:

sanity graphql deploy --playground --force

Update your build script in package.json to:

{
  "scripts": {
    "graphql-deploy": "sanity graphql deploy --playground --force"
  }
}

The --force flag tells Sanity to deploy the GraphQL API without asking for confirmation about breaking changes. This is perfectly safe in your situation since you're just getting started and don't have existing GraphQL queries that would break.

Why This Happened

When you ran sanity upgrade, it updated your Sanity packages to newer versions that changed how certain system fields are typed in GraphQL. The CLI detected these as "breaking changes" because existing GraphQL queries might theoretically be affected, but in practice, these changes (making fields nullable instead of required) rarely cause actual issues.

Other Useful Flags

While you're at it, here are some other helpful flags for the sanity graphql deploy command:

  • --dataset <name> - Deploy to a specific dataset
  • --tag <tag> - Deploy to a specific tag (defaults to 'default')
  • --no-playground - Deploy without the public GraphQL playground
  • --dry-run - Test the deployment without actually deploying

Good luck with your first Sanity project! 🎉

In my studio/package.json i have
"@sanity/base": "^1.149.10",
"@sanity/cli": "^1.149.9",
"@sanity/components": "^1.149.10",
"@sanity/core": "^1.149.12",
"@sanity/dashboard": "^1.149.10",
"@sanity/default-layout": "^1.149.10",
"@sanity/default-login": "^1.149.11",
"@sanity/desk-tool": "^1.149.10",
"@sanity/studio-hints": "^1.149.10",
"date-fns": "^1.30.1",
"prop-types": "^15.7.2",
"react": "^16.13.1",
"react-dom": "^16.13.1",
"sanity-plugin-dashboard-widget-document-list": "^0.0.10",
"sanity-plugin-dashboard-widget-netlify": "^1.0.1"
I have deleted the contents of nod_modules and npm install again. I can start the project again, but would like to hopefully understand what is wrong or what to not do next time 🙂 Any ideas? Did you encounter this problem? I wonder if i should roll back to lower versions?
I forgot my web/package.json
"devDependencies": {
  "@sanity/block-content-to-react": "^2.0.7",
  "@sanity/image-url": "^0.140.18",
  "date-fns": "^1.30.1",
  "dotenv": "^8.0.0",
  "eslint": "^5.16.0",
  "eslint-config-standard": "^12.0.0",
  "eslint-config-standard-react": "^7.0.2",
  "eslint-plugin-import": "^2.17.3",
  "eslint-plugin-node": "^9.1.0",
  "eslint-plugin-promise": "^4.1.1",
  "eslint-plugin-react": "^7.19.0",
  "eslint-plugin-standard": "^4.0.0",
  "gatsby": "^2.9.2",
  "gatsby-plugin-postcss": "^2.0.7",
  "gatsby-plugin-react-helmet": "^3.2.4",
  "gatsby-source-sanity": "^4.0.3",
  "postcss-import": "^12.0.1",
  "postcss-preset-env": "^6.6.0",
  "prettier-eslint-cli": "^4.7.1",
  "react": "^16.13.1",
  "react-dom": "^16.13.1",
  "react-helmet": "^5.2.1"
},

Seems like it stalls on the graphql api deployment that’s in the build step. Try
sanity graphql deploy
from the studio folder?
Seems like it stalls on the graphql api deployment that’s in the build step. Try
sanity graphql deploy
from the studio folder?
worked. thank you.

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?