GraphQL query stops working - seems cache issue

Confirming that this is an issue we are also experiencing. We use graphql_compose to generate schema.

I need to debug further but I'm observing the same behaviour on a site with GraphQL 8.x-4.9 and GraphQL Compose 2.2.1.

In our case all queries fail until the cache is rebuilt (a single cache clear consistently fixes the issue temporarily). Issue is sporadic and we haven't identified a consistent trigger for it.

We're running GraphQL 8.x-4.8 and are seeing the same issue w/ GraphQL queries not working after each deploy to production. We don't use GraphQL Compose.

A query to get the Commerce Orders in the GraphQL explorer, returns errors like this:

{
    "errors": [
        {
            "message": "Cannot query field \u0022derivative\u0022 on type \u0022FieldItemTypeImage\u0022.",
            "extensions": {
                "category": "graphql"
            },
            "locations": [
                {
                    "line": 88,
                    "column": 25
                }
            ]
        },
        {
            "message": "Cannot query field \u0022derivative\u0022 on type \u0022FieldItemTypeImage\u0022.",
            "extensions": {
                "category": "graphql"
            },
            "locations": [
                {
                    "line": 121,
                    "column": 25
                }
            ]
        },
...

After clearing cache a couple of more times, it starts working again.

Any update on this error ?
We suddenly have it too since this morning, our production site is broken, and clear cache doesn't solve anything :(

Hello,

We face the same issue here once with an apdated site (we restored backups to make it work again) and now we face it with a new dev website with Drupal 11.1.5 and GraphQL 8.x-4.11 and Graphql_compose 2.3.0.

We noticed this error GraphQL\Error\SyntaxError : Syntax Error: Cannot parse the unexpected character "\uc9". dans GraphQL\Language\Lexer->readToken()

And realized that this bug happend only after translation updates, if we revert our prod site, enable a new module that updates translation we have this bug again.
Are any of you using multilingual sites? Maybe this is a lead to find out what is wrong here?

After some disabling and enabling of graphQL and GraphQL Compose and returning to the explorer page between modifications we also notice that unticking the "Enable Singuliarize" checkbox in the "String inflector" tab of graphql_compose settings produces the same bug.
Maybe this issue is a graphql_compose issue and not a graphql issue.

Heya everyone,

If you are using graphql while also using memcache as your default cache backend, please introduce these lines to your settings:

$settings['cache']['bins']['graphql_ast'] = 'cache.backend.database';
$settings['cache']['bins']['graphql_results'] = 'cache.backend.database';

This should let graphql use the database tables for caching purposes which seems to make the random issues go away.

I didn't find this fix by myself but got permission to share it to the community.

Hope this helps!

Looks like the changes in #3491736: Cache collision when multiple servers are using the same schema plugin are breaking.

web/modules/contrib/graphql/src/Plugin/GraphQL/Schema/SdlSchemaPluginBase.php

Method: getCacheId

$this->getConfiguration()['server_id'] is not always set. It's weirdly only sometimes set?

It looks like its set in the server and not the schema?

Full ID returned: full:graphql_compose:my_server
- /admin/config/graphql/servers/manage/core_graphql/explorer
- /admin/config/graphql/servers/manage/core_graphql/voyager

Partial ID returned: full:graphql_compose
- /admin/config/graphql/servers/manage/core_graphql/validate

Somethings not right or I'm missing something here.
Is it an order or operation or missing data?

It seems weird that server_id is only set in a setConfiguration in web/modules/contrib/graphql/src/Entity/Server.php - Is it supposed to be saved in the `schema_configuration` yaml?

Any call to `getConfiguration` outside of Server::configuration() being called, will not have server_id set on the schema.

Quick fix for the desperate:
https://imgur.com/a/IZmJzXs

Copy the server name to the schema_configuration nesting in your schema yaml and config:import it, then don't save over it with the server form.

I'm unsure, quick check and maybe this was missed, and it fixes the cache failing (not the deprecated warning).

$cid = $this->getCacheId('schema');
for web/modules/contrib/graphql/src/Plugin/GraphQL/Schema/AlterableComposableSchema.php

Side note: I still feel like it a bandaid on the symptom, and it's still going to be getting that deprecated in getCacheId, all we're doing is separating the caches by adding in the getCacheId again. It feels really abrasive for a cache id method.

Theres probably a couple of missing setConfigurations around the place if it 100% needs to be added by Server.php

    // $server = Server::load('my_server_thingy');

    $plugin_config = ['server_id' => $server->id()];
    /** @var \Drupal\graphql\Plugin\SchemaPluginInterface $plugin */
    $plugin = $manager->createInstance($schema, $plugin_config);
    if ($plugin instanceof ConfigurableInterface && $config = $this->get('schema_configuration')) {
      $schema_config = $config[$schema] ?? [];
      $plugin->setConfiguration($schema_config + $plugin_config);
    }

So we need this boilerplate to be used every single time someone wants to use or inspect a schema? It might be nicer to add a setServerId surely?

Seeing the same issue on a site with translation, also using compose, truncating the cache tables seem to be the only fix.

Explorer shows none of the schema, but just found if I can to graphql compose and save configuration it fixes the issue, so seems like it more likely a compose issue

Compose nukes all GraphQL caches on save. That could be what you’re seeing.

Thanks@almunnings
The patch is applied correctly in Graphql 8.x-4.12

We are still getting the error even after applying the patch.

This issue may be due to memcache as the GraphQL module caches complex PHP structures — especially the parsed AST (Abstract Syntax Tree) and query metadata. These structures are sometimes not well-serialized or unserialized across Memcache.

Hey esteban.arias,

After adding

$settings['cache']['bins']['graphql_ast'] = 'cache.backend.database';
$settings['cache']['bins']['graphql_results'] = 'cache.backend.database';

in settings file, did you observe any performance issues e.g increased db load.

We are also trying to implement the above solution but considering any performance issues compared to memcache.

I have seen this issue locallly on ddev without memcached so I don't think setting caches to use database will fix the issue.

I have noticed for me, the schema gets built without graphql_compose portion, so I think that part is failing silently, and have created a related issue: https://www.drupal.org/project/graphql_compose/issues/3541422

Merged the small fixes in the pull request, thanks @almunnings!

I'm not sure that this will fix the cache issue here, please test if this helps.

Then I can make a new 4.x release soon.

We are still seeing this issue with release 4.13 containing the changes from #24 but we are also using GraphQL Compose so the actual issue in our case may be there.

Out of curiosity, are folks experiencing this issue using Redis for their cache? I'm trying to see if there's a pattern.

We have explicitly moved the graphql_ast and graphql_results cache bins out of Redis and to the database.

When the problem occurs we can resolve it by solely clearing the ast cache by running drush cc bin graphql.ast.

This is definitely still affecting our production sites. This may be an act of desperation, but I ended up getting Claude Haiku to analyze the graphql repo and the file SdlSchemaPluginBase.php with the question "Is there a reason this file would end up with stale data in cache.graphql.ast?"

This may or may not help, but the response is worth looking at in case any of it is going in the right direction:

Reasons for Stale Cache Data in cache.graphql.ast

1. No Schema File Change Detection

The cache is stored with CacheBackendInterface::CACHE_PERMANENT (lines 200, 228 in SdlSchemaPluginBase.php) and is tagged only with ['graphql']. However, the cache doesn't invalidate when the underlying GraphQL schema definition files (.graphqls files) change. The system only reads these files when:

• The cache misses
• Development mode is enabled (which disables caching entirely)

Problem: If someone updates a .graphqls file after caching, the cache remains stale because there's no file system monitoring or hook to detect file changes.

2. No Module Hook for Cache Invalidation

There's no hook_modules_installed(), hook_modules_uninstalled(), or similar hook that would invalidate the graphql cache tag when schema-related modules are enabled/disabled. This means:

• Adding new schema extensions won't clear the cache
• Disabling modules with schema definitions won't clear the cache
• The cache persists across module lifecycle changes

3. Extension Definitions Not Cached Independently

In getExtensionDocument() (line 237-249), the extension AST is not cached - it's reparsed every time. However, the full schema document (which includes extensions) is cached with CACHE_PERMANENT. If extension definitions change, the full schema cache becomes stale.

4. Configurable Schema Cache Per Server

For configurable schema plugins (line 292-299), if the server_id configuration isn't properly set, it falls back to a deprecation warning. Misconfigured servers could share stale cache entries.

5. Development Mode Only Affects Caching

When not in development mode, caching is always used regardless of actual schema state. There's no way to manually invalidate the cache short of:

• Clearing it via cache management UI/CLI
• Waiting for system maintenance
• Enabling/disabling modules (with the proper cache tag invalidation)

Recommended Fixes

1. Add a hook that invalidates the graphql cache tag when modules are installed/uninstalled
2. Add file modification time checking to detect .graphqls file changes
3. Cache extension documents separately so they can be updated independently
4. Add a cache invalidation endpoint/command for schema-related changes

Same, still seeing the same issue in production

The AI slop explanation does not seem useful to me - when a module is enabled Drupal already clears the cache.

The question here is why there is an invalid schema in your AST cache. Could this be Graphql Compose related? Please test again with latest 8.x-4.13 release or 5.0.0-beta1 and let me know if you have more info.

We also experienced this in prod. We fixed it by clearing the cache a few times.

We are using GraphQL Version: 8.x-4.13 and GraphQL Compose Version: 2.4.1.

Given that all messages in this issue mention that they're using GraphQL Compose and we've heard no reports of people without GraphQL compose experiencing this issue, I'm moving the issue to their issue queue.

This is still an issue:
GraphQL\Error\Error: Unknown type "SiteSettingEntityUnion". Cannot extend type "SiteSettingGlobalString" because it is not defined. Cannot extend type "MediaBynder" because it is not defined. Cannot extend type "NodeListingPage" because it is not defined. Unknown type "NodeListingPage". Unknown type "NodeParagraphUnion". Cannot extend type "TermProductCategory" because it is not defined. Cannot extend type "ParagraphCardScroller" because it is not defined. Unknown type "NodeUnion". Cannot extend type "ParagraphSolutionsCardPackage" because it is not defined. Unknown type "NodeUnion". Cannot extend type "NodeCollection" because it is not defined. Unknown type "NodeParagraphUnion". Cannot extend type "SiteSettingSearch" because it is not defined. Cannot extend type "NodeProduct" because it is not defined. Unknown type "NodeProduct". Unknown type "NodeProduct". Unknown type "NodeProduct". Unknown type "ParagraphUnion". Unknown type "MediaUnion". Did you mean "Mutation"? Unknown type "NodeUnion". Unknown type "SiteSettingEntityUnion". Cannot extend type "Link" because it is not defined. Did you mean "Int"? Unknown type "SchemaInformation". Cannot extend type "MediaBynder" because it is not defined. Unknown type "Translation". Cannot extend type "NodeArticle" because it is not defined. Unknown type "Translation". Cannot extend type "NodeCampaign" because it is not defined. Unknown type "Translation". Cannot extend type "NodeCollection" because it is not defined. Unknown type "Translation". Cannot extend type "NodeEnhancedPdp" because it is not defined. Unknown type "Translation". Cannot extend type "NodeEnhancedPlp" because it is not defined. Unknown type "Translation". Cannot extend type "NodeEvent" because it is not defined. Unknown type "Translation". Cannot extend type "NodeListingPage" because it is not defined. Unknown type "Translation". Cannot extend type "NodePerson" because it is not defined. Unknown type "Translation". Cannot extend type "NodeProduct" because it is not defined. Unknown type "Translation". Cannot extend type "NodePage" because it is not defined. Unknown type "Translation". Cannot extend type "NodeSystem" because it is not defined. Unknown type "Translation". Cannot extend type "Link" because it is not defined. Did you mean "Int"? Unknown type "LinkAttributes". Unknown type "BlockUnion". Unknown type "Cursor". Unknown type "Cursor". Unknown type "ConnectionSortKeys". Unknown type "ParagraphListingPageGroupConnection". Unknown type "Cursor". Unknown type "Cursor". Unknown type "ConnectionSortKeys". Unknown type "ParagraphTabConnection". Unknown type "Cursor". Unknown type "Cursor". Unknown type "ConnectionSortKeys". Unknown type "MediaBynderConnection". Cannot extend type "ParagraphListingPageGroup" because it is not defined. Unknown type "EdgeNode". Cannot extend type "ParagraphTab" because it is not defined. Unknown type "EdgeNode". Cannot extend type "MediaBynder" because it is not defined. Unknown type "EdgeNode". Cannot extend type "Image" because it is not defined. Did you mean "SkuImage"? Unknown type "ImageStyleAvailable". Unknown type "ImageStyleDerivative". Unknown type "RouteUnion". Did you mean "Mutation"? Cannot extend type "RouteUnion" because it is not defined. Did you mean "Mutation"? Unknown type "RouteRedirect". Unknown type "SitemapFilterInput". Unknown type "SitemapResult". Unknown type "TypeSitemapFilterInput". Unknown type "TypeSitemapResult". Cannot extend type "NodeArticle" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeCampaign" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeCollection" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeEnhancedPdp" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeEnhancedPlp" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeEvent" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeListingPage" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodePerson" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeProduct" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodePage" because it is not defined. Unknown type "CacheTagsInterface". Cannot extend type "NodeSystem" because it is not defined. Unknown type "CacheTagsInterface". in GraphQL\Validator\DocumentValidator::assertValidSDLExtension() (line 316 of /mnt/www/html/sbdpolaris01test/vendor/webonyx/graphql-php/src/Validator/DocumentValidator.php).

The extensions don't work because the base definitions from graphql_compose don't work.

This is causing us a lot of problems in production. Currently our only solution is rebuilding the cache. But the problem causes the (headless) site to go down.

We're also working on this one over at #3541422: Schema can get cached without GraphQL compose contributions - with partial success on GraphQL 5.x Beta 2. I'd wait for a new alpha from here (alpha3) if thinking of trying it out, as #3590358: Upstream 5.0.0-rc1 compatibility changes is still not RTBC.

Best we can figure out so far, the schema cache gets "partially" collected/invalidated by redis/memcache when the server is full. - at the GraphQL level. The GraphQL Compose schema builds only if the cache for ast is empty.

What we're seeing is the AST is full, but the rest of the cache is boned. So GraphQL Compose never gets the correct event fired to go and do it's thing.

If you wanna push everything over to the database, you're be lookin at:

$settings['cache']['bins']['graphql_ast'] = 'cache.backend.database';
$settings['cache']['bins']['graphql_results'] = 'cache.backend.database';
$settings['cache']['bins']['graphql_definitions'] = 'cache.backend.database';
$settings['cache']['bins']['graphql_results'] = 'cache.backend.database';
$settings['cache']['bins']['graphql_compose_definitions'] = 'cache.backend.database';

That should move all the gql based cache bins to non volatile cache.

You could then monitor those database tables, and help us figure out if something is just spaming the crap out of them and filling them up for you.

Without some kind of "more info" on why your cache is filling up, I don't know where to look. The error seems to be the result of a partially primed/invalidated cache.