Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#8,769 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@Pixelshaped arbeitet bereits daran.

Seit 27.10.2026.

  • #8770 von @Pixelshaped — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
php, symfony
Bereich
backend, performance

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
PHP
Sterne
2.6k
Forks
987
Ø Merge
1 T. 22 Std.
Gemergte PRs (30 T.)
87

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus api-platform/core

Alle Issues in api-platform/core

Ähnliche Issues

Weitere Issues zu PHP

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.