Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

ResourceMetadataCompatibilityTest fails when api-platform/elasticsearch is autoloaded

クローズ 初心者向け
  • 何か問題がありますか？
#8,495 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
84/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
elasticsearch, php
領域
testing

調査の方向性

src/Metadata/Tests/Extractor/ResourceMetadataCompatibilityTest.php から始め、特に 731 行目付近の buildStateOptions() を確認し、src/Metadata/Extractor/XmlResourceExtractor.php の 477 行目付近にある extractor のロジックと比較してください。monorepo のルートおよび分離されたコンポーネント環境から、指定された PHPUnit テストを実行してください。両方がパスし、elasticsearchOptions ブランチが利用可能な場合はカバーされ、それ以外の場合は null のままであれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
PHP
スター
2.6k
フォーク
987
平均マージ
1日 7時間
マージ済み PR（30日）
84

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

api-platform/core のほかの issue

api-platform/core の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。