Skip to content

fix(openapi): coerce metadata parameters in user-supplied openapi operation#8229

Merged
soyuka merged 3 commits into
api-platform:4.3from
soyuka:fix/openapi-query-parameter-getname-8182
Jun 3, 2026
Merged

fix(openapi): coerce metadata parameters in user-supplied openapi operation#8229
soyuka merged 3 commits into
api-platform:4.3from
soyuka:fix/openapi-query-parameter-getname-8182

Conversation

@soyuka
Copy link
Copy Markdown
Member

@soyuka soyuka commented Jun 3, 2026

Summary

ApiPlatform\OpenApi\Model\Operation::parameters is documented as ?Parameter[] where Parameter is ApiPlatform\OpenApi\Model\Parameter. The array was untyped beyond ?array, so passing a ApiPlatform\Metadata\QueryParameter (or any other Metadata\Parameter) was silently accepted and only blew up much later inside OpenApiFactory::hasParameter() with an opaque Call to undefined method ApiPlatform\Metadata\QueryParameter::getName().

This patch guards OpenApiFactory::hasParameter() (the call site that actually triggers the failure) with an instanceof Parameter check and throws ApiPlatform\Metadata\Exception\InvalidArgumentException naming the offending class and pointing the user at the resource-level parameters option used for Metadata\Parameter instances.

Why guard at the consumption site, not coerce

The two Parameter classes (Metadata\Parameter, OpenApi\Model\Parameter) live in different namespaces with no inheritance link and incompatible APIs (getKey() vs getName()). Coercing one into the other would hide misuse, lose information (default schema fabrication, ambiguous in inference, merge order with getOpenApi()), and entrench the trap. A clear exception at the point of use teaches correct usage and matches the existing PHPDoc.

Reproduction

#[ApiResource(openapi: new \ApiPlatform\OpenApi\Model\Operation(parameters: [new \ApiPlatform\Metadata\QueryParameter(key: 'bar')]))]

Before: opaque undefined method getName() deep in OpenApiFactory.
After: ApiPlatform\Metadata\Exception\InvalidArgumentException naming QueryParameter and directing to the resource-level parameters option.

Test plan

  • OpenApiFactoryTest::testMetadataParameterInOpenApiOperationParametersThrows covers the rejection path.
  • Pre-existing OpenApi tests still pass (one unrelated pre-existing failure on testInvoke about a 422 response description, present on the base commit).

Fixes #8182

@soyuka soyuka force-pushed the fix/openapi-query-parameter-getname-8182 branch from cfa73cb to f71b391 Compare June 3, 2026 13:54
…eter

Operation::parameters is documented as ?Parameter[] (OpenApi\Model\Parameter)
but accepted any array element at runtime. Passing a Metadata\QueryParameter
(or any Metadata\Parameter) inside the user-supplied openapi Operation
crashed with an opaque "undefined method getName()" deep in OpenApiFactory.

Guard hasParameter() with an instanceof Parameter check and throw an
ApiPlatform\Metadata\Exception\InvalidArgumentException naming the
offending class and pointing at the resource-level "parameters" option for
Metadata\Parameter declarations.

Fixes api-platform#8182
@soyuka soyuka force-pushed the fix/openapi-query-parameter-getname-8182 branch from f71b391 to 382d1f2 Compare June 3, 2026 13:59
soyuka added 2 commits June 3, 2026 16:20
Drop the resource-level "parameters" hint per PR feedback; keep the
expected/got class names which already point at the misuse.
@soyuka soyuka merged commit fd08d29 into api-platform:4.3 Jun 3, 2026
105 of 106 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant