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:

[markjenkinson]

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 the id field 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 the id field matching: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX".

Environment

System:
OS: macOS 10.14.6
CPU: (4) x64 Intel(R) Core(TM) 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

[markjenkinson]

While trying to debug this issue, I noticed that the issue persists regardless of what plugin I use, so using gatsby-source-apiserver instead of gatsby-source-thirdparty (they both do the same thing, that is pull down remote data) does not eliminate the error. So, I'm thinking the issue must be with either Gatsby or gatsby-plugin-remote-images. Thoughts?

[purefun]

gatsby-source-twitter + gatsby-plugin-remote-images also produce the issue.

[LekoArts]

And by removing the remote-images plugin everything works fine again?

[markjenkinson]

The error is specific to the localImage___NODE which is what the gatsby-plugin-remote-images creates once it has pulled down the image locally. So yes, removing the remote-images-plugin eliminates the possibility for this error to occur.

I think there's a clue in the Error when it says "There is no corresponding node with the id field matching: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" which indicates the node has yet to be created, and it seems that when there's a prexisting cache, certain conditions are satisfied that prevent the node from being created.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[Prabuela]

gatsby-source-contenta also product this error

gatsby develop

success open and validate gatsby-configs - 0.027s
success load plugins - 0.071s
success onPreInit - 0.006s
success initialize cache - 0.035s
success copy gatsby files - 0.051s
success onPreBootstrap - 0.020s
Starting to fetch data from Drupal
articles fetched 9
fetch Drupal data: 192.076ms
success source and transform nodes - 0.437s

ERROR

UNHANDLED REJECTION Encountered an error trying to infer a GraphQL type for: image___NODE. There is no corresponding node with the id field matching: "xxxx............".

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[cburgos0511]

I am currently having the same issue. Were you able to solve it?

[markjenkinson]

I am currently having the same issue. Were you able to solve it?

No, the only work around I've found was to perform a gatsby clean before every build. I've just baked it into my build workflow.

[cburgos0511]

That's what I've been doing. It's quite annoying. Thank you, Mark.

[MaxwellKendall]

I am currently having the same issue. Were you able to solve it?

No, the only work around I've found was to perform a gatsby clean before every build. I've just baked it into my build workflow.

@markjenkinson are you using gatsby cloud in your build work flow? I'm assuming not; cleaning cache in gatsby cloud apparently requires a manual user action every time.

[markjenkinson]

@markjenkinson are you using gatsby cloud in your build work flow? I'm assuming not; cleaning cache in gatsby cloud apparently requires a manual user action every time.

No, we're using Netlify, and the production builds don't have this issue. It's only the local builds, using the gatsby develop or netlify dev --live commands that this issue persists.