search

gatsbyjs / gatsby

The best React-based framework with performance, scalability and security built in.
https://www.gatsbyjs.com
MIT License
55.27k stars 10.31k forks source link

gatsby-source-graphql plugin causing Validating Rendering Engines Failure when introspection is disabled #35174

Closed ksirrah13 closed 2 years ago

ksirrah13 commented 2 years ago

Preliminary Checks

Description

Similar to this issue https://github.com/gatsbyjs/gatsby/issues/24603 I am getting the following error when attempting to build after upgrading to Gatsby v4. This only happens when I am using a graphql endpoint that has introspection disabled (our prod endpoint). When using a staging endpoint which allows introspection this error does not occur.

failed Validating Rendering Engines - 1.361s

 ERROR #98001  WEBPACK

Built Rendering Engines failed validation failed validation.

Please open an issue with a reproduction at https://github.com/gatsbyjs/gatsby/issues/new for more help

  Error: Worker exited before finishing task

  - index.js:113 ChildProcess.<anonymous>
    [bug-repro]/[gatsby-worker]/dist/index.js:113:45

  - child_process.js:277 Process.ChildProcess._handle.onexit
    internal/child_process.js:277:12

The error thrown by the worker is Source GraphQL API: HTTP error 400 Bad Request

Even though I have specified createSchema in the plugin options for gatsby-source-graphql it still appears to be attempting to get the schema via introspection when evaluating createSchemaCustomization for the plugin.

What I have noticed is that the plugin options available in createSchemaCustomization suddenly loses the createSchema property when this method is being executed by a worker during the Validating Rendering Engines step. All other times the plugin options seem complete and correctly include the createSchema property.

Because there is no value for createSchema one of these times, the plugin attempts to get the schema via introspection from the graphql endpoint during createSchemaCustomization, however the graphql endpoint doesn't allow introspection which results in Source GraphQL API: HTTP error 400 Bad Request and the build fails. https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-graphql/src/gatsby-node.js#L65

I haven't been able to determine why the plugin options are incomplete in these cases, but this is preventing us from being able to use gatsby v4 with our production graphql server.

Reproduction Link

https://github.com/ksirrah13/gatsby-bug-repro.git

Steps to Reproduce

  1. Download repo and checkout branch repro-create-schema-bug
  2. npm install and npm run build
  3. Notice build failure ...

Note that in the repro I am using a broken graphql api link https://rickandmortyapi.com/graphql_broken. This is to mimic the behavior of using a graphql endpoint that doesn't have introspection enabled. I have reproduced this using our production endpoint without introspection (requires auth that I can't share for this repro), but you can substitute any other graphql endpoint here as long as it doesn't allow introspection to see the same issue.

Also note that in gatsby-node.js if I set defer:false it will build successfully even with the broken graphql endpoint. This seems to be because it will skip Generating Rendering Engines and correctly use the createSchema function from the plugin in this case instead of incorrectly querying the graphql endpoint for the schema.

Expected Result

Successful build

Actual Result

failed Validating Rendering Engines - 1.361s

 ERROR #98001  WEBPACK

Built Rendering Engines failed validation failed validation.

Please open an issue with a reproduction at https://github.com/gatsbyjs/gatsby/issues/new for more help

  Error: Worker exited before finishing task

  - index.js:113 ChildProcess.<anonymous>
    [bug-repro]/[gatsby-worker]/dist/index.js:113:45

  - child_process.js:277 Process.ChildProcess._handle.onexit
    internal/child_process.js:277:12

Environment

System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 14.17.6 - ~/.volta/tools/image/node/14.17.6/bin/node
    Yarn: 1.22.15 - ~/.volta/tools/image/yarn/1.22.15/bin/yarn
    npm: 6.14.15 - ~/.volta/tools/image/node/14.17.6/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 99.0.4844.74
    Safari: 15.0
  npmPackages:
    gatsby: ^4.11.0-next.2 => 4.11.0-next.2
    gatsby-source-graphql: ^4.11.0-next.1 => 4.11.0-next.1

Config Flags

No response

pieh commented 2 years ago

I haven't been able to determine why the plugin options are incomplete in these cases, but this is preventing us from being able to use gatsby v4 with our production graphql server.

My first guess would be the fact that buildSchema plugin option is a function (which can't be serialized) and ending up in engine bundle as undefined.

There are 2 ways to address it:

Also note that in gatsby-node.js if I set defer:false it will build successfully even with the broken graphql endpoint. This seems to be because it will skip Generating Rendering Engines and correctly use the createSchema function from the plugin in this case instead of incorrectly querying the graphql endpoint for the schema.

This problem seem to happen in engines so it make sense that getting rid of all DSG or SSR pages (which then cause skipping engines generation and validation) "fixes" it

ksirrah13 commented 2 years ago

Thank you @pieh for the suggestions. For the workaround suggested would you then recommend creating a local patched plugin of gatsby-source-graphql to accept a string file path to the schema? Or is there a better approach to extending/modifying plugin functionality like this? Our use case is simple enough that this could work without a function call for createSchema here.

Also, in case others have a similar situation I wanted to point out that even though we weren't using DSG or SSR pages, Gatsby v4 determined we needed to create the rendering engines because of an exported config in storybook-addon-gatsby, https://github.com/prismicio-community/storybook-addon-gatsby/blob/main/src/index.ts#L16. Removing this addon "fixes" this issue for now, however once we add any SSR or DSG pages I expect this issue will become a blocker again.

github-actions[bot] commented 2 years ago

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 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. 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! 💪💜

github-actions[bot] commented 2 years ago

Hey again!

It’s been 60 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 comment on 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! 💪💜

fbouchezexagroup commented 1 year ago

Hello, this bug is still not resolved. Are you working on patches proposed by @pieh ?

bashidagha commented 1 year ago

For me it's funny. I had a SSR query in my page and when run npm run build, I stuck in there, just remove SSR query and problem solved!