Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

GraphQL response cache can miss keys on invalidation under concurrent requests

Aperta
  • Qualcosa non va?
#15,523 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
graphql, laravel, php
Ambito
api, backend-api-design

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
PHP
Stelle
4.9k
Fork
647
Merge medio
1g 20h
PR unite (30g)
113

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di statamic/cms

Tutte le issue di statamic/cms

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.