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

ResourceMetadataCompatibilityTest fails when api-platform/elasticsearch is autoloaded

Aperta Adatta ai principianti
#8,495 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à
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
84/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
elasticsearch, php
Ambito
testing

Direzione di ricerca

Inizia da src/Metadata/Tests/Extractor/ResourceMetadataCompatibilityTest.php, in particolare da buildStateOptions() intorno alla riga 731, e confrontalo con la logica dell’estrattore in src/Metadata/Extractor/XmlResourceExtractor.php intorno alla riga 477. Esegui il test PHPUnit indicato dalla root del monorepo e nell’ambiente isolato del componente; il lavoro è completato quando entrambi passano, mentre il ramo elasticsearchOptions è coperto quando disponibile e rimane null altrimenti.

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

Descrizione

Q A
API Platform version 4.3, 4.4, main
PHP version 8.4 / 8.5

ResourceMetadataCompatibilityTest fails as soon as ApiPlatform\Elasticsearch\State\Options is autoloadable, which is the case for anyone running the component tests from the monorepo root:

$ vendor/bin/phpunit src/Metadata/Tests/Extractor/ResourceMetadataCompatibilityTest.php

There were 2 failures:
1) …::testValidMetadata#0 with data ('…XmlResourceExtractor', …XmlResourceAdapter)
Failed asserting that two objects are equal.
-        'stateOptions' => null
+        'stateOptions' => ApiPlatform\Elasticsearch\State\Options Object (...)

Both data sets fail, and the rendered diff also shows unrelated keys such as strictQueryParameterValidation, which sends you looking in the wrong place — removing src/Elasticsearch/State/Options.php makes the whole test green again, so stateOptions is the only real difference.

Cause

The fixture declares stateOptions: {elasticsearchOptions: {index: foo_index}}, and both extractors build the real object when the component is installed:

// src/Metadata/Extractor/XmlResourceExtractor.php:477
if (isset($stateOptions->elasticsearchOptions) && class_exists(ElasticsearchOptions::class)) {
    return new ElasticsearchOptions(...);
}

The expectation, on the other hand, returns null unconditionally:

// src/Metadata/Tests/Extractor/ResourceMetadataCompatibilityTest.php:731
case 'elasticsearchOptions':
    return null;

So the assertion only holds when api-platform/elasticsearch is absent. CI never notices, because phpunit-components runs each component from its own directory with its own vendor/, where the class does not exist. $configuration is even read and then unused, which suggests the null was a placeholder.

Beyond the failure, this means the elasticsearchOptions branch of buildStateOptions() has no assertion on it in any environment.

Fix

Mirror the extractors: build the options when the class exists, keep returning null otherwise. The test then passes both from the monorepo root and in the isolated component job. PR follows.

Lingua principale
PHP
Stelle
2.6k
Fork
982
Merge medio
1g 19h
PR unite (30g)
77

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.