Gatsby Cloud id "[object Object]" is nullish. error

[kara-todd]

Description

We've been running a Gatsby 2.x build on Gatsby Cloud with gatsby-source-craft for a few weeks now. Intermittently, we are getting the error posted below. The NodeType varies... it's been news_articles_Entry, pages_pages_Entry, etc. It seems to only happen on incremental builds... In other words the message Craft config version has not changed since last sourcing. Checking for content changes since "dateTime" always appears. At this point... we only have like a 60-50% success rate on builds. Generally, they have to be manually re-triggered, and sometimes with the cache fully cleared.

"gatsby-source-craft" threw an error while running the sourceNodes lifecycle:

Node "newsarticlesEntry" with id "[object Object]" is nullish.

    510 |         }
    511 |         // And source, if needed
> 512 |         await sourceNodeChanges(config, { nodeEvents });
          |         ^
   513 |     }
   514 |     await cache.set(`CRAFT_CONFIG_VERSION`, remoteConfigVersion);
   515 |     await cache.set(`CRAFT_LAST_CONTENT_UPDATE`, remoteContentUpdateTime);

  Error: Node "news_articles_Entry" with id "[object Object]" is nullish.
    internal/process/task_queues.js:97:5
    [www]/[gatsby-source-craft]/[gatsby-graphql-source-toolkit]/src/source-nodes/fetch-nodes/fetch-nodes.ts:21:13
  - fetch-nodes.ts:21 Object.fetchNonNullishNodesById
  - task_queues.js:97 processTicksAndRejections
  - create-nodes.ts:13 Object.createNodes
  - async Promise.all
 
    [www]/[gatsby-source-craft]/[gatsby-graphql-source-toolkit]/src/source-nodes/node-actions/create-nodes.ts:13:20
  - source-node-changes.ts:35 sourceNodeChanges

    [www]/[gatsby-source-craft]/[gatsby-graphql-source-toolkit]/src/source-nodes/source-node-changes.ts:35:3
    [www]/[gatsby-source-craft]/gatsby-node.js:512:9
  - gatsby-node.js:512 Object.exports.sourceNodes

    [www]/[gatsby]/src/utils/api-runner-node.js:485:16
  - api-runner-node.js:485 runAPI

Steps to reproduce

Inconsistent. I know for sure it is happening on Gatsby Cloud and seems to only occur on incremental builds.

Additional info

• Node version v12.22.1
• Gatsby version Gatsby CLI version: 2.19.2
• Gatsby version: 2.32.11
• gatsby-source-craft@1.0.0

[kara-todd]

It looks like our nodeChanges query is returning null for the nodesDeletedSince siteId

query nodeChanges {  
 nodesUpdatedSince (since: "2021-04-16 22:02:24") { nodeId nodeType siteId}
 nodesDeletedSince (since: "2021-04-16 22:02:24") { nodeId nodeType siteId}
}

{
  "data": {
    "nodesUpdatedSince": [
      {
        "nodeId": "45346",
        "nodeType": "uploads_Asset",
        "siteId": "1"
      },
      {
        "nodeId": "45350",
        "nodeType": "news_articles_Entry",
        "siteId": "1"
      },
      {
        "nodeId": "45593",
        "nodeType": "uploads_Asset",
        "siteId": "1"
      },
      {
        "nodeId": "45596",
        "nodeType": "uploads_Asset",
        "siteId": "1"
      },
      {
        "nodeId": "45597",
        "nodeType": "news_articles_Entry",
        "siteId": "1"
      }
    ],
    "nodesDeletedSince": [
      {
        "nodeId": "45322",
        "nodeType": "news_articles_Entry",
        "siteId": null
      },
      {
        "nodeId": "45356",
        "nodeType": "news_articles_Entry",
        "siteId": null
      }
    ]
  }
}

[kara-todd]

Not to keep talking to myself here but... :)

It seems like this might be an issue with gatsby-hepler? The resolver doesn't appear to return the siteId. Is this not needed for deletions? If so, it should probably be removed from the deletedNodes map function.

[andris-sevcenko]

That's a great observation about the site id and deleted nodes. I'll see if I can reproduce the troubles you're describing!

[kara-todd]

@andris-sevcenko I've been trying to get clarification on what the signature should be for the nodeEvents map... The gatsby-graphql-toolkit documentation says:

The remoteId field here must contain values for all of the fields declared in the ID fragment (in this example: __typename and id)

I think this is causing my issue. It seems like the node isn't being matched properly... but I'm not sure what the match criteria is... Do you have any insight into this?

[andris-sevcenko]

@kara-todd Here's what I think is happening:

This function generates the GraphQL fragment that lists all the fields Gatsby will use for a node ID.

So, since site id is missing for deleted nodes, this line generates an incorrect key.

So, the end result would be that Gatsby never internally deletes this node and doesn't delete it from relations, either. So, if for any reason Gatsby figured it needed to update a node that it didn't know should have been deleted, you would get the Node "newsarticlesEntry" with id "[object Object]" is nullish., because Gatsby would ask Craft for the contents, assuming it exists.

So the issue is actually on the gatsby-helper plugin side.

[andris-sevcenko]

@kara-todd Okay.

Can you change your Gatsby Helper plugin requirement in the composer.json file to

"require": {
  "craftcms/gatsby-helper": "dev-develop#56c8a4cc36292fae21aa246d02163c2e8bb18a77 as 1.0.0",
  "...": "..."
}

and run composer update?

Can you test this out for a while and see if that resolves these issues going forward?

[kara-todd]

Thanks @andris-sevcenko !

I tried this out locally, but it seems there is currently a bug where deleting an entry causes an internal error.

I believe the issue is that use Craft as Craft; is not at the top of the gatsby-helper/Deltas.php file... thus leading to the error Class 'craft\gatsbyhelper\services\Craft' not found on this line.

I also ran into an issue where the $deletedNodes nodeId wouldn't resolve. I created a local version of the plugin and changed gql/resolvers/DeletedNode.php#L30 to 'nodeId' => $element['elementId'],.

This seems to be working locally, but I didn't want to commit my hacked version. 🙃
Could you review these changes and update the dev version as needed?

Also happy to open a PR if needed. I just thought the changes were pretty minor.

[andris-sevcenko]

One of these days being lazy will pay off, I swear. I cleaned up the code. Can you update the commit hash to 00a84132ddd53ff0ed4ff6495061094438463cad and try again, please?

Sorry for doing such a half-assed job previously.

[kara-todd]

Thanks again @andris-sevcenko. I tested this on my local and QA and the changes look good. I've gone ahead and started running this live. I'll report back on if we are still seeing any routine failures

[andris-sevcenko]

Appreciate it, @kara-todd!

[mcclaskiem]

I am getting a similar issue where intermittently incremental builds will fail and continue to do so until I "Clear Cache and Deploy" via Netlify. I am also using the Gatsby cache plugin in order to speed up builds.

Most of the time I get the below error:

11:41:49 AM: info Checking Craft config version.
11:41:49 AM: info Craft config version has not changed since last sourcing. Checking for content changes since "2021-04-14 19:29:47".
11:41:50 AM: info Sourcing changes for 8 nodes.
11:41:50 AM: error "gatsby-source-craft" threw an error while running the sourceNodes lifecycle:
11:41:50 AM: Missing Gatsby node definition for remote type contentSlide_BlockType
11:41:50 AM:   510 |         }
11:41:50 AM:   511 |         // And source, if needed
11:41:50 AM: > 512 |         await sourceNodeChanges(config, { nodeEvents });
11:41:50 AM:       |         ^
11:41:50 AM:   513 |     }
11:41:50 AM:   514 |     await cache.set(`CRAFT_CONFIG_VERSION`, remoteConfigVersion);
11:41:50 AM:   515 |     await cache.set(`CRAFT_LAST_CONTENT_UPDATE`, remoteContentUpdateTime);
11:41:50 AM: 
11:41:50 AM: 
11:41:50 AM:   Error: Missing Gatsby node definition for remote type contentSlide_BlockType

The last two times I have gotten this error:

4:37:54 PM: info Checking Craft config version.
4:37:54 PM: info Craft config version has not changed since last sourcing. Checking for content changes since "2021-04-22 17:22:17".
4:37:55 PM: info Sourcing changes for 64 nodes.
4:37:55 PM: error UNHANDLED REJECTION Missing Gatsby node definition for remote type slide_BlockType
4:37:55 PM: 
4:37:55 PM: 
4:37:55 PM:   Error: Missing Gatsby node definition for remote type slide_BlockType

Let me know if you need any more info!

[kara-todd]

@andris-sevcenko unfortunately... it looks like this is still cropping up for builds on me as well. I'm going to try and dig through the logs more and find the correct conditions to replicate the issue.

[andris-sevcenko]

@mcclaskiem what's the type of contentSlide_BlockType?

[andris-sevcenko]

@kara-todd appreciate all your help - it's not very feasible for me to reproduce this without knowing how, indeed.

[kara-todd]

@andris-sevcenko Just as an update. I'm still looking into this... I worked together with Vladar to get improve the error reporting in graphqph-toolkit (gatsbyjs/gatsby-graphql-toolkit#32.) I'm going to run this in production for a while and hopefully that will uncover the issue in more detail. I haven't been able to create a reproducible test case locally.

Please bear with me... Thank you. 🙏🏻

[andris-sevcenko]

@kara-todd I just wanted the record to show that @vladar is the best. Without him, it's unlikely Craft would have decent Gatsby support.

[mcclaskiem]

@mcclaskiem what's the type of contentSlide_BlockType?

It’s a Super Table field within a matrix block @andris-sevcenko

[kara-todd]

@andris-sevcenko I'll edit this with a better follow up tomorrow, but I think I finally figured out the core of the issue. The build is failing when there is a pending entry. I confirmed that the node causing the build to fail has a status of "pending"

Should pending entries be included in the sourceNodes check? I would think these should be excluded... it might be on my end. I'll do more digging tomorrow.

[dbvisel]

That accords with what I've been seeing on Netlify – I'm getting a crashing build pretty often after editors add new content, which I can't replicate, though I wouldn't be surprised if they're building while an entry is pending.

[andris-sevcenko]

@mcclaskiem Sounds like you're not using the latest version of SuperTable - 2.6.7 was the Gatsby Helper plugin compatibility release for SuperTable. If you update to that, your error should disappear!

[andris-sevcenko]

@dbvisel @kara-todd ah, interesting. This sort of rings a bell. What Craft version are you both using?

For background, Craft 3.6.8 introduced a new setting for GraphQL schemas for querying drafts, revisions, and inactive elements. If updating to 3.6.8, a migration automatically added those for all existing schemas (since it was always allowed before), but, if you start with 3.6.8 or later, those settings would be disabled by default and it would be easy to miss.

So, if you started on 3.6.8 or later and did not notice the new settings, you would start running into this.

Can you both check if it's the case? To me, it would make sense if non-live elements were not required, however, drafts will definitely be required for live preview to work.

[dbvisel]

I'm on Craft Pro 3.6.14, which I just updated to – my site was started before 3.6.8. I have those three boxes checked in the schema I'm using (and I'm not sure when they started being checked). Would unchecking them change things?

(and thanks, as ever, for the support!)

[andris-sevcenko]

@dbvisel they got checked when added as you updated to 3.6.8 and unchecking them would not help. Let's wait for a follow up by @kara-todd.

[kara-todd]

Ok. I think I’ve worked this down to a reproducible case. What I believe is happening here is that Gatsby (via gatsby-graphql-source-toolkit) is somehow unaware of pending entires. This means when they show up on the sourceNodes query the IDs aren't matched and query fails.

Pre step:

If using yarn (not sure how to do this in npm) set a resolutions definition to pull the latest version of gatsby-graphql-source-toolkit. This fix will give better error reporting to make debugging easier.

"resolutions": {
  "gatsby-graphql-source-toolkit": "2.0.1"
}

Here's the steps to reproduce:

1. Run gatsby build to ensure a cache is built. This will trigger an incremental build on the next step.
2. Create a "pending" status entry. (i.e. It must have a future publish date but be published.)
3. Run gatsby build again. This time it should fail with Error: Node "[entry_type_from_step2]" with id "{ __typename: '[entry_type_from_step2]', id: '[entry_id_from_step2]', siteId: '1' }" is nullish.

My initial thought here was just to add status: '["pending", "live"]' to the EntryInterface sourcingParams... However, This didn't seem to fix the issue. I then wondered if there was an issue just sourcing new entries entirely. However, taking the same steps as above and immediately publishing the entry built just fine. For some reason, the pending entries aren't following the same pattern as the live.

Do you have any insight as to why this might be @andris-sevcenko?

Also, to answer your previous question. I'm on Craft CMS 3.6.12 and all of those boxes were checked for me.

[andris-sevcenko]

Okay, I fixed this in the gatsby-source-craft plugin. I Will see if we can publish a new version today.

[brandonkelly]

Gatsby Helper 1.0.2 is out now with the additional fix.