Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#8,769 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@Pixelshaped y travaille déjà.

Depuis le 27/10/2026.

  • #8770 par @Pixelshaped — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
php, symfony
Domaine
backend, performance

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
PHP
Étoiles
2.6k
Forks
987
Merge moyen
1 j 22 h
PR mergées (30 j)
87

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de api-platform/core

Toutes les issues de api-platform/core

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.