Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

GraphQL response cache can miss keys on invalidation under concurrent requests

Abierto
  • ¿Algo no está bien?
#15,523 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
graphql, laravel, php
Área
api, backend-api-design

Línea de trabajo

Start with src/GraphQL/ResponseCache/DefaultCache.php, especially the tracked-key logic at lines 38–52, and trace how get(), put(), and handleInvalidationEvent() interact. Reproduce with concurrent queries and a shared cache store as described; then add regression coverage for concurrent caching and invalidation. Done means content events invalidate every cached response, including when requests overlap.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

graphql
Bug description

Statamic\GraphQL\ResponseCache\DefaultCache invalidates by forgetting the keys it has recorded under gql-cache:tracked-responses. That list is maintained in track() with a read-modify-write (Cache::get → push → Cache::put) that is not atomic, so when several GraphQL requests are cached at the same moment they overwrite each other's copy of the list and some keys are never recorded.

A response whose key was dropped is never forgotten by handleInvalidationEvent(). It keeps being served until statamic.graphql.cache.expiry runs out (60 minutes by default), no matter how many EntrySaved or other content events fire in between.

We hit this on a headless site where the front end fires the entry-by-slug query, the listing query and a metadata query for the same page in parallel. A slug was queried a minute before its entry was created, so the null response was cached; the entry was then published from the CP (which did fire EntrySaved, and other keys were flushed), but this one key had been lost from the tracked list and the page 404'd for the full hour while its siblings rendered.

I would have expected every cached response to be dropped on a content event, whatever the request concurrency.

How to reproduce
  1. Fresh install with GraphQL enabled and a cache store that is shared across PHP workers (database here; redis or file behave the same, only array hides it).
  2. Serve the site with more than one PHP worker, for example: 
    cd public && PHP_CLI_SERVER_WORKERS=8 php -S 127.0.0.1:8123 index.php
  3. Fire 30 distinct queries concurrently, then compare the tracked list with what was actually stored: 
    php artisan cache:clear
seq 1 30 | xargs -P 30 -I{} curl -s -o /dev/null -X POST http://127.0.0.1:8123/graphql \
  -H 'Content-Type: application/json' \
  -d '{"query":"{ entry(collection: \"pages\", slug: \"missing-{}\") { id } }"}'
php artisan tinker --execute 'echo count(Cache::get("gql-cache:tracked-responses", []))." tracked, ".DB::table("cache")->where("key","like","%gql-cache:%")->where("key","not like","%tracked%")->count()." stored";'
  4. Fire any content event and count what survives: 
    php artisan tinker --execute 'event(new Statamic\Events\EntrySaved(Statamic\Facades\Entry::query()->first())); echo DB::table("cache")->where("key","like","%gql-cache:%")->where("key","not like","%tracked%")->count()." still cached";'

Five runs of step 3 on a database cache store gave 29 of 30, 19 of 30, 30 of 30, 28 of 30 and 27 of 30 tracked. After the last run, step 4 left 3 responses in the cache that no event will ever remove. With a single worker (php artisan serve without PHP_CLI_SERVER_WORKERS) the requests are serialised and it never reproduces, which is probably why it has gone unnoticed.

The code in question, unchanged on 6.x:

https://github.com/statamic/cms/blob/6.x/src/GraphQL/ResponseCache/DefaultCache.php#L38-L52

Suggested fix

Drop the tracked list and key responses under a generation number instead, so invalidation is a single atomic operation:

protected function getCacheKey(Request $request)
{
    return 'gql-cache:'.$this->generation().':'.md5($query).'_'.md5(json_encode($vars));
}

public function handleInvalidationEvent(Event $event)
{
    if (Cache::increment('gql-cache:generation') === false) {
        Cache::add('gql-cache:generation', 1); // database store returns false on a missing key
    }
}

Superseded generations age out at the existing expiry. Two details worth keeping if you go this way: read the generation once in get() and reuse it in put() (the middleware calls them either side of executing the query), so a response computed before an event cannot land in the new generation; and note that DatabaseStore::increment() returns false rather than creating a missing key, so the counter needs seeding. We are running this shape in production behind our own ResponseCache binding and can send a PR if it would help.

Logs

No response

Environment
Environment
Laravel Version: 13.33.0
PHP Version: 8.5.0
Composer Version: 2.8.12
Environment: local
Debug Mode: ENABLED
Maintenance Mode: OFF
Timezone: UTC
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: database
Database: sqlite
Logs: stack / single
Mail: log
Queue: database
Session: database

Storage
public/storage: NOT LINKED

Statamic
Addons: 2
License Key: Not set
Sites: 3
Stache Watcher: Enabled (auto)
Static Caching: Disabled
Version: 6.34.0 PRO

Statamic Addons
cboxdk/statamic-mcp: 3.0.0
statamic/eloquent-driver: 5.11.1

Statamic Eloquent Driver
Addon Settings: file
Asset Containers: file
Assets: eloquent
Blueprints: file
Collection Trees: eloquent
Collections: file
Entries: eloquent
Fieldsets: file
Form Submissions: eloquent
Forms: file
Global Sets: file
Global Variables: eloquent
Navigation Trees: eloquent
Navigations: file
Revisions: eloquent
Sites: file
Taxonomies: file
Terms: eloquent
Tokens: eloquent
Installation

Existing Laravel app

Additional details

Headless: the GraphQL API is the only consumer of the content, statamic.routes.enabled is false and the entries live in the database via the Eloquent driver. Production runs the same versions on MySQL with the database cache store and two or more PHP workers per instance.

Lenguaje dominante
PHP
Estrellas
4.9k
Forks
647
Merge medio
1 d 8 h
PR fusionados (30 d)
100

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de statamic/cms

Todos los issues de statamic/cms

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.