gatsby: [gatsby-source-contentful] TypeError: Cannot read property 'internal' of null

Description

Build fails with:

Fetch Contentful data: 250.798ms
success source and transform nodes — 1.107 s
error UNHANDLED REJECTION

  TypeError: Cannot read property 'internal' of undefined

  - infer-graphql-type.js:227 _.uniqBy.v
    [blumenhaus]/[gatsby]/dist/schema/infer-graphql-type.js:227:44

  - lodash.js:4296 baseUniq
    [blumenhaus]/[lodash]/lodash.js:4296:35

  - lodash.js:8418 Function.uniqBy
    [blumenhaus]/[lodash]/lodash.js:8418:40

  - infer-graphql-type.js:227 inferFromFieldName
    [blumenhaus]/[gatsby]/dist/schema/infer-graphql-type.js:227:15

  - infer-graphql-type.js:354 _.each
    [blumenhaus]/[gatsby]/dist/schema/infer-graphql-type.js:354:23

  - lodash.js:4925
    [blumenhaus]/[lodash]/lodash.js:4925:15

  - lodash.js:3010 baseForOwn
    [blumenhaus]/[lodash]/lodash.js:3010:24

  - lodash.js:4894
    [blumenhaus]/[lodash]/lodash.js:4894:18

  - lodash.js:9342 Function.forEach
    [blumenhaus]/[lodash]/lodash.js:9342:14

  - infer-graphql-type.js:333 _inferObjectStructureFromNodes
    [blumenhaus]/[gatsby]/dist/schema/infer-graphql-type.js:333:5

  - infer-graphql-type.js:403 inferObjectStructureFromNodes
    [blumenhaus]/[gatsby]/dist/schema/infer-graphql-type.js:403:10

  - build-node-types.js:150 createNodeFields
    [blumenhaus]/[gatsby]/dist/schema/build-node-types.js:150:30

  - build-node-types.js:183 fields
    [blumenhaus]/[gatsby]/dist/schema/build-node-types.js:183:25

  - Array.forEach

Steps to reproduce

I have republished a few contentful nodes, so these have more than one version. The develop build started failing immediately after that.

I believe this issue might be related to #4479. I have taken the suggested steps, installed and ran the contentful-links-cleaner, which showed no broken links in the space.

I have uninstalled and re-installed node_modules.

Environment

Gatsby: 2.0.0-beta.14
Gatsby-cli: 2.0.0-beta.3
Node: 10.6.0
OS: Windows 10

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 6
Comments: 23 (10 by maintainers)

Commits related to this issue

Change to handle contentful TypeError issue #6949 — committed to jamenamcinteer/gatsby by jamenamcinteer 6 years ago

Most upvoted comments

This issue happens when there’s a GraphQL query that requests a field which is not in the Contentful API responses. Usually it’s because of a reference field in Contentful being left empty.

The real problem here IMHO is that the error from Gatsby is completely useless in identifying what query failed.

amclin on Mar 28, 2019

Hi all, I came across this issue from searching Google.

I’m working on a project using WordPress + Gatsby and this issue comes up when I delete an ACF flexible content field in WordPress. I believe this is a problematic and the responsible party is the one that creates/updates the GraphQL schema. I believe Gatsby is responsible for that?

This is a big deal because when developing back-end layout builder fields, clients often will want to remove a column, or module. Because of this, the build will fail.

Deleting the .cache folder in Gatsby root fixes it and so I think the temporary fix might be to delete this .cache within the build script. Unless theres something I’m not understanding correctly.

heyflorin on Jun 19, 2019

As I completely agree with you @KyleAMathews on the fact that all issues are not fixable, I do think that closing issues as non-fixable or non-reproducible is a human job.

People should always be told what they are doing wrong. If the issue is low quality, tell it. If the bug can’t be reproduced, tell it. Always be verbose. After that if nothing happens, only then I think auto-closing is acceptable.

The issue not gathering any replies is not always low quality or not affecting people. The current bot implementation doesn’t evaluate the importance of issues in any way. Many of the issues that have been or are being auto-closed are labeled as “to be reviewed”. That doesn’t seem right to me.

At least we should add labels to problematic issues. Many OSS projects are doing that and I think that helps the project and people using the software a lot.

akselinurmio on Feb 11, 2019

“covering things up” is pretty strong language 😃

FWIW, I don’t think it’s problematic — software always has problems — we as an ecosystem/core team need to focus on the most pressing issues — the ones with the largest impact and affecting the most users. If an issue doesn’t get any comments or isn’t fixed, then in all likelihood it’s not affecting that many people.

Also, as @pieh mentioned, this issue isn’t fixable given it doesn’t have a reproduction.

Auto-closing low-quality issues like this leaves room for better issues you can create with good reproductions 😉

KyleAMathews on Feb 11, 2019

@akolybelnikov @ndjamenamarmon @ldelbeccaro Have you tried deleting the .cache folder? otherwise try that.

stoltzrobin on Sep 11, 2018