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

Doctrine ORM/ODM resource metadata collection factory runs outside the metadata cache since 4.2.16 (priority -50 vs `.cached` at -10)

Aperta
  • Qualcosa non va?
#8,769 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Pixelshaped ci sta già lavorando.

Dal 27/10/2026.

  • #8770 di @Pixelshaped — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
php, symfony
Ambito
backend, performance

Direzione di ricerca

Read the Doctrine ORM and ODM service definitions in src/Symfony/Bundle/Resources/config/doctrine_orm.php and src/Symfony/Bundle/Resources/config/doctrine_mongodb_odm.php, then compare their decoration priorities with the cached factory in metadata/metadata.php. Reproduce with a Symfony app using Doctrine and profile a request that serializes an item with many related resources. Done when both factories run behind the cache and the issue’s repeated calls are avoided without changing the response.

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

Descrizione

API Platform version(s) affected: 4.2.16 and later, including 5.0.x (measured on 5.0.2) and main

Description

Since #7739 (merged 2026-02-13 as 6f85f2aa3157, first released in v4.2.16), the Doctrine resource metadata collection factories are decorated at priority -50 instead of 40:

  • api_platform.doctrine.orm.metadata.resource.metadata_collection_factory in src/Symfony/Bundle/Resources/config/doctrine_orm.php
  • api_platform.doctrine.odm.metadata.resource.metadata_collection_factory in src/Symfony/Bundle/Resources/config/doctrine_mongodb_odm.php

api_platform.metadata.resource.metadata_collection_factory.cached (CachedResourceMetadataCollectionFactory) is at -10 in metadata/resource.php and has been the lowest-priority (outermost) decorator since 2.7. With -50, the Doctrine factory now wraps the cache instead of sitting behind it, so DoctrineOrmResourceCollectionMetadataFactory::create() is no longer cached and re-runs on every create() call, including one ManagerRegistry::getManagerForClass() call per resource it processes.

Moving from 40 to -50 only jumps over the cache decorator (-10) and Elasticsearch (also 40, so a tie). The discussion in #7739 never mentions the cache, so the bypass looks unintended. For comparison, the Laravel wiring (src/Laravel/ApiPlatformDeferredProvider.php) builds new CacheResourceCollectionMetadataFactory(new EloquentResourceCollectionMetadataFactory(...)), i.e. its equivalent stays inside the cache.

Measured in a Symfony app on 5.0.2, serializing one item that references ~1,000 related resources (JSON-LD):

  • 3,407 uncached DoctrineOrmResourceCollectionMetadataFactory::create() calls and 27,270 ManagerRegistry::getManagerForClass() calls for that single request, coming from AbstractItemNormalizer::normalizeCollectionOfRelations and the JSON-LD ItemNormalizer::resolveType.
  • About 24% of the profiled request (Xdebug profile: 13,206 → 9,340 ms with the factory back inside the cache).
  • Without the profiler (Xdebug off, median of 5 runs): ~905 ms → ~685 ms. SQL queries and response size are unchanged and the JSON output is byte-identical.

How to reproduce

  1. Symfony app with API Platform ≥ 4.2.16 and Doctrine ORM.
  2. A resource with a to-many relation and one item with a few hundred related items.
  3. GET that item (application/ld+json) while profiling (Blackfire / Xdebug / SPX).
  4. DoctrineOrmResourceCollectionMetadataFactory::create() and ManagerRegistry::getManagerForClass() show up thousands of times for the one request, although the metadata below the Doctrine factory is cached.

The wiring is visible directly in the config: priority -50 for the Doctrine factory vs -10 for .cached (lower priority = outermost).

Possible Solution

Use a priority between the cache (-10) and the other regular factories, for both ORM and ODM. The smallest change is -5; going back to 40 should work too, unless something from #7739 needs to run after a lower-priority factory (I couldn't find a reason in the PR).

->decorate('api_platform.metadata.resource.metadata_collection_factory', null, -5)

Workaround for applications: redeclare the Doctrine factory service in config/services.yaml with decoration_priority: -5 (repeating its constructor arguments from the bundle definition). That restores the cached behaviour here.

Additional Context

DoctrineOrmResourceCollectionMetadataFactory::create() mutates the Operations object it receives from the decorated factory. Once its input comes from the cache's local in-memory store, that object is shared across calls. It is idempotent today (the same values are written each time), so it should be fine, but it's worth keeping in mind (or cloning) if the factory ever becomes dependent on anything other than the resource class.

Lingua principale
PHP
Stelle
2.6k
Fork
987
Merge medio
1g 22h
PR unite (30g)
87

Preparare l'ambiente

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 api-platform/core

Tutte le issue di api-platform/core

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.