gatsby: UNHANDLED REJECTION Encountered an error trying to infer a GraphQL type for: `localImage___NODE`. There is no corresponding node with the `id` field matching:
Description
Having just upgraded to Gatsby 2.5.15, gatsby develop started producing this ERROR:
UNHANDLED REJECTION Encountered an error trying to infer a GraphQL type for:
localImage___NODE. There is no corresponding node with theidfield matching: “XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX”.
If I perform a gatsby clean before every develop there are no errors. But as soon as I try to run gatsby develop on an existing cache, the errors kill the build.
It appears that when running off cache, for whatever reason the gatsby-plugin-remote-images attempts to resolve before the gatsby-source-thirdparty plugin resolves, and everything fails.
I’ve spent the day researching this, and have come up fairly empty. And I can’t exactly tell if the issue is with Gatsby, the gatsby-source-thirdparty plugin, or the gatsby-plugin-remote-images plugin.
Steps to reproduce
package.json
"dependencies": {
...
"gatsby-plugin-remote-images": "^1.0.7",
...
"gatsby-source-thirdparty": "^1.0.5",
...
}
gatsby-config.js
{
resolve: 'gatsby-source-thirdparty',
options: {
url: 'https://thirdparty.api/public/v1/posts/?news_group_id=1&start=0&limit=3',
name: 'Posts',
payloadKey: 'posts',
},
},
{
resolve: 'gatsby-plugin-remote-images',
options: {
nodeType: 'thirdParty__Posts',
imagePath: 'remote_image_url',
},
}
gatsby clean
gatsby develop
– stop develop server—
gatsby develop
Expected result
The following graphql should provide access to a remote image that has been transformed into a local image :
allThirdPartyPosts(sort: { order: DESC, fields: [date] }) {
edges {
node {
id
title
remote_image_url
localImage {
childImageSharp {
fluid(maxWidth: 512, maxHeight: 512) {
src
}
}
publicURL
}
date(formatString: "MMMM D, YYYY [at] h:mm A")
slug
excerpt
}
}
}
Actual result
ERROR
UNHANDLED REJECTION Encountered an error trying to infer a GraphQL type for:
localImage___NODE. There is no corresponding node with theidfield matching: “XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX”.
Environment
System: OS: macOS 10.14.6 CPU: (4) x64 Intel® Core™ i5-3470S CPU @ 2.90GHz Shell: 3.2.57 - /bin/bash Binaries: Node: 10.15.3 - /usr/local/bin/node npm: 6.9.0 - /usr/local/bin/npm Languages: Python: 2.7.10 - /usr/bin/python Browsers: Chrome: 76.0.3809.132 Firefox: 68.0.2 Safari: 12.1.2 npmPackages: gatsby: ^2.15.14 => 2.15.14 gatsby-cli: ^2.7.47 => 2.7.47 gatsby-image: ^2.2.18 => 2.2.18 gatsby-plugin-feed: ^2.3.12 => 2.3.12 gatsby-plugin-manifest: ^2.2.16 => 2.2.16 gatsby-plugin-offline: ^2.2.10 => 2.2.10 gatsby-plugin-react-helmet: ^3.1.7 => 3.1.7 gatsby-plugin-remote-images: ^1.0.7 => 1.0.7 gatsby-plugin-sass: ^2.1.14 => 2.1.14 gatsby-plugin-sharp: ^2.2.21 => 2.2.21 gatsby-plugin-stripe: ^1.2.2 => 1.2.2 gatsby-source-apiserver: ^2.1.3 => 2.1.3 gatsby-source-filesystem: ^2.1.22 => 2.1.22 gatsby-source-thirdparty: ^1.0.5 => 1.0.6 gatsby-transformer-remark: ^2.6.22 => 2.6.22 gatsby-transformer-sharp: ^2.2.14 => 2.2.14 npmGlobalPackages: gatsby-cli: 2.5.15 gatsby-project-website: 1.0.0
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 3
- Comments: 19 (4 by maintainers)
No, the only work around I’ve found was to perform a
gatsby cleanbefore every build. I’ve just baked it into my build workflow.Same issue here using Gatsby v3.6.1. Just to be clear
gatsby cleanis not an option because it ruins incremental builds! Shouldn’t this be reopened? Any Gatsby developer around to bring some light on the issue?I had the same issue and I am hosting using gatsby cloud. You have to manually trigger the clean cache and build. Could we reopen this issue?
Same issue with Gatsby Cloud and Strapi CMS
Am also having the same issue when using gatsby cloud with incremental builds (the reason I’m using gatsby cloud) pulling from contentful