Broken GraphQL integration after environment change

r0skar commented 1 year ago

Describe the bug

We run Vizy and were previously affected by https://github.com/verbb/vizy/issues/196 - After the upgrade to 2.0.12 everything was working again.

However, we have now deployed the application to a new server (same code, same composer.lock), but the error appeared again: Tried to load an unregistered type \"articleRichText_quote_BlockType\". This can indicate both a typo in the query or an issue with the schema used.

The error is the same as before (https://github.com/verbb/vizy/issues/196), but this time the explorer itself seems to work - just the query throws. Everything still works on the "old" environment with the same config. I can also use the block in the CMS editor, but I cant query it.

Steps to reproduce

Query a vizy field block in GQLi explorer.
Returns "Something went wrong when processing the GraphQL query."

Craft CMS version

Craft Pro 4.4.3

Plugin version

2.0.12

Multi-site?

No

Additional context

PHP Version: 8.2.3

engram-design commented 1 year ago

So it's working in the GraphiQL interface, but not in your front-end? What are you using on the front-end? It's not a caching issue is it (caching the GQL query)? Is it potentially the schema you're using?

r0skar commented 1 year ago

So it's working in the GraphiQL interface.

No, it is not - sorry for the confusion. What I meant is that the explorer side-panel works (as opposed to #196), but the query itself doesnt.

Full log:

2023-03-18 07:35:26 [web.ERROR] [craft\errors\GqlException] Tried to load an unregistered type "articleRichText_quote_BlockType". This can indicate both a typo in the query or an issue with the schema used. {"trace":["#0 /home/XXX/vendor/webonyx/graphql-php/src/Type/Schema.php(350): craft\\gql\\TypeLoader::loadType()","#1 /home/XXX/vendor/webonyx/graphql-php/src/Type/Schema.php(326): GraphQL\\Type\\Schema->loadType()","#2 /home/XXX/vendor/webonyx/graphql-php/src/Utils/AST.php(580): GraphQL\\Type\\Schema->getType()","#3 /home/XXX/vendor/webonyx/graphql-php/src/Utils/TypeInfo.php(436): GraphQL\\Utils\\AST::typeFromAST()","#4 /home/XXX/vendor/webonyx/graphql-php/src/Validator/Rules/OverlappingFieldsCanBeMerged.php(272): GraphQL\\Utils\\TypeInfo::typeFromAST()","#5 /home/XXX/vendor/webonyx/graphql-php/src/Validator/Rules/OverlappingFieldsCanBeMerged.php(164): GraphQL\\Validator\\Rules\\OverlappingFieldsCanBeMerged->internalCollectFieldsAndFragmentNames()","#6 /home/XXX/vendor/webonyx/graphql-php/src/Validator/Rules/OverlappingFieldsCanBeMerged.php(95): GraphQL\\Validator\\Rules\\OverlappingFieldsCanBeMerged->getFieldsAndFragmentNames()","#7 /home/XXX/vendor/webonyx/graphql-php/src/Validator/Rules/OverlappingFieldsCanBeMerged.php(63): GraphQL\\Validator\\Rules\\OverlappingFieldsCanBeMerged->findConflictsWithinSelectionSet()","#8 /home/XXX/vendor/webonyx/graphql-php/src/Language/Visitor.php(414): GraphQL\\Validator\\Rules\\OverlappingFieldsCanBeMerged->GraphQL\\Validator\\Rules\\{closure}()","#9 /home/XXX/vendor/webonyx/graphql-php/src/Language/Visitor.php(470): GraphQL\\Language\\Visitor::GraphQL\\Language\\{closure}()","#10 /home/XXX/vendor/webonyx/graphql-php/src/Language/Visitor.php(277): GraphQL\\Language\\Visitor::GraphQL\\Language\\{closure}()","#11 /home/XXX/vendor/webonyx/graphql-php/src/Validator/DocumentValidator.php(224): GraphQL\\Language\\Visitor::visit()","#12 /home/XXX/vendor/webonyx/graphql-php/src/Validator/DocumentValidator.php(116): GraphQL\\Validator\\DocumentValidator::visitUsingRules()","#13 /home/XXX/vendor/webonyx/graphql-php/src/GraphQL.php(153): GraphQL\\Validator\\DocumentValidator::validate()","#14 /home/XXX/vendor/webonyx/graphql-php/src/GraphQL.php(93): GraphQL\\GraphQL::promiseToExecute()","#15 /home/XXX/vendor/craftcms/cms/src/services/Gql.php(504): GraphQL\\GraphQL::executeQuery()","#16 /home/XXX/vendor/craftcms/cms/src/controllers/GraphqlController.php(177): craft\\services\\Gql->executeQuery()","#17 [internal function]: craft\\controllers\\GraphqlController->actionApi()","#18 /home/XXX/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array()","#19 /home/XXX/vendor/yiisoft/yii2/base/Controller.php(178): yii\\base\\InlineAction->runWithParams()","#20 /home/XXX/vendor/yiisoft/yii2/base/Module.php(552): yii\\base\\Controller->runAction()","#21 /home/XXX/vendor/craftcms/cms/src/web/Application.php(302): yii\\base\\Module->runAction()","#22 /home/XXX/vendor/craftcms/cms/src/web/Application.php(627): craft\\web\\Application->runAction()","#23 /home/XXX/vendor/craftcms/cms/src/web/Application.php(281): craft\\web\\Application->_processActionRequest()","#24 /home/XXX/vendor/yiisoft/yii2/base/Application.php(384): craft\\web\\Application->handleRequest()","#25 /home/XXX/web/index.php(26): yii\\base\\Application->run()","#26 {main}"],"memory":11990768,"exception":"[object] (craft\\errors\\GqlException(code: 0): Tried to load an unregistered type \"articleRichText_quote_BlockType\". This can indicate both a typo in the query or an issue with the schema used. at /home/XXX/vendor/craftcms/cms/src/gql/TypeLoader.php:39)"}

r0skar commented 1 year ago

@engram-design Any news on this? This issue prevents us to deploy the site to production. We either need an ETA or we need to remove Vizy for good from the site and redo the rich-text part with a more reliable plugin, which would be a shame, because Vizy is a really nice plugin when it works and we spent a lot of time building custom blocks for it.

engram-design commented 1 year ago

Sorry for the delay, I've just been struggling to reproduce this one, sorry! I just wanted to confirm you've cleared all the caches in Utilities? It's incredibly surprising that the nodes show in the explorer sidebar, but the query doesn't work, as they really do use the same logic.

engram-design commented 1 year ago

Just to quickly post what I'm getting:

engram-design commented 1 year ago

I've gained a copy of your database from https://github.com/verbb/vizy/issues/202 and the only way I can reproduce your issue is by picking "Public Schema" in the schema selection.

But that's simply a matter of the section isn't allowed to be queried with that schema.

Otherwise, I can't figure out why on a different environment, you'd get a different GraphQL response like this.

Any insight you can provide on your new server compared to the previous one? Is it a production/staging server, compared to your local dev environment? Is it using the correct schema from the front-end?

tom-bywild commented 1 year ago

It is still reproducible for me when explicitly selecting the Frontend-schema. GraphQL can query the plain HTML elements just fine, but for the custom blocks, it fails.

Could you please verify that the following query works for you. The article should be available in the database we shared. Thanks!

query Query {
  entries(section: "article", slug: "daily-darwin-tuesday-april-4-2023") {
    ... on article_default_Entry {
      articleRichText {
        nodes {
          ... on articleRichText_twitter_BlockType {
            type
            tagName
            content
          }
        }
      }
    }
  }
}

devinpitcher commented 1 year ago

@engram-design Any updates here?

engram-design commented 1 year ago

@tom-bywild Thanks for the clarification, something odd is seemingly going on, as I can query that (caches cleared of course).

Still continuing to investigate...

tom-bywild commented 1 year ago

I just wanted to document the different query-variants which worked or didn't work. While testing them one by one, the API suddenly worked again. I will leave my initial post below for reference, but here's what I did:

strip away all fields from the query, and only fetch the articleRichText with rawNodes and html
as this worked, I added the __typename as well, which also worked
I then added back the query for the Twitter-block field, with only its __typename, which also worked
then I added back all the other fields for that block + tested other blocks with different entries, and they all worked.

I really don't have an explanation for that, as we pruned all our caches, even the revisions.

Original text

Very odd. I poked around and maybe the root cause is related to JSON-serialization. What works for me is querying the rawNodes, which are just a stringifed JSON representation of all nodes.

Yet when I select nodes with actual content to fetch, it breaks with an unknown error. Please note that only fetching nodes with __typename works.

Screenshot of query with working rawNodes

Screenshot of nodes-fetch w/o content, but working __typename

Screenshot of everything working 🎉

engram-design commented 1 year ago

Thanks for the summary, that's very strange behaviour, particularly because it's intermittent. I'll continue investigating how this could be happening...

verbb / vizy