Gatsby: Catch data access errors from gatsby-node.js (`cannot read property VAR_NAME of undefined`) that are from GraphQL calls and show prettier error with link to try the query in graphiql

[KyleAMathews]

When users are trying to create pages in Gatsby by querying graphql data and then using the queried data, they frequently can get stymied by obscure GraphQL-related errors. These are difficult to understand on their own merits and can be especially difficult to fix as the cycle for fixing them is slow as each attempt at fixing errors means restarting the gatsby develop process.

An example of this:

We should a) catch errors from plugins and detect if they're a GraphQL related error (and re-throw if not) and b) print out a better error which clearly points to their graphql query as the fault (or other possible problems) and generally points them to trying to debug the query in graphiql once the gatsby develop process starts.

[aamorozov]

If it's helpful, another example error from gatsby-source-graphql plugin - there are ~ 150 queries in build time in my project and the server might respond with 500 error on one of them, but since there is no way to debug and/or suppress that error the whole build fails. It would be very helpful if gatsby's graphql could either log a more verbose output or provide the way to suppress such errors. It does output the template which the query fails on.

$ gatsby build
success open and validate gatsby-configs — 0.008 s
success load plugins — 0.168 s
success onPreInit — 0.463 s
success delete html and css files from previous builds — 0.004 s
success initialize cache — 0.005 s
success copy gatsby files — 0.012 s
success onPreBootstrap — 0.004 s
success source and transform nodes — 0.668 s
success building schema — 0.082 s
success createPages — 0.568 s
success createPagesStatefully — 0.029 s
success onPreExtractQueries — 0.000 s
success update schema — 0.059 s
success extract queries from components — 0.184 s
error 
The GraphQL query from /home/dev/app/frontend/src/templates/templateName.js failed.

Errors:
  Unexpected token < in JSON at position 0

Looks like it's throwing from query-runner here https://github.com/gatsbyjs/gatsby/blob/2cd7bfad261b6e13ba8233a3f2a3836cd3cd1ce2/packages/gatsby/src/internal-plugins/query-runner/query-runner.js#L58

[KyleAMathews]

@aamorozov that's definitely something that needs fixed as well /cc @freiksenet

Could you file another issue for it however as it has a different root cause / needed fix than this issue.

[aamorozov]

Sure, added one here: https://github.com/gatsbyjs/gatsby/issues/10487

[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!

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

[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.

Thanks again for being part of the Gatsby community!

[deammer]

@KyleAMathews I apologize for reviving this thread but was any work done against this issue before it was moved to "Done"? I'm asking because I'm running into problems with gatsby-source-wordpress:

error Plugin gatsby-source-wordpress returned an error
  TypeError: Cannot read property 'data' of undefined

I definitely think this could be handled better in that plugin's code, but I also see value in improving the error handling in gatsby-node, if possible.

[raydot]

Agreed! Similar error, having a pretty tough time debugging. #

[mafrosis]

The debug experience with Gatsby and graphql errors is terrible! Work on this front would definitely make gatsby more accessible to non-nodejs experts