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

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

Abierto
  • ¿Algo no está bien?
#8,769 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Pixelshaped ya está trabajando en esto.

Desde el 27/10/2026.

  • #8770 de @Pixelshaped — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php, symfony
Área
backend, performance

Línea de trabajo

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.

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

Descripción

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.

Lenguaje dominante
PHP
Estrellas
2.6k
Forks
987
Merge medio
1 d 22 h
PR fusionados (30 d)
87

Preparar el entorno

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

Todos los issues de api-platform/core

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.