fix(openapi): coerce metadata parameters in user-supplied openapi operation#8229
Merged
soyuka merged 3 commits intoJun 3, 2026
Merged
Conversation
1 task
cfa73cb to
f71b391
Compare
…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
f71b391 to
382d1f2
Compare
Drop the resource-level "parameters" hint per PR feedback; keep the expected/got class names which already point at the misuse.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ApiPlatform\OpenApi\Model\Operation::parametersis documented as?Parameter[]whereParameterisApiPlatform\OpenApi\Model\Parameter. The array was untyped beyond?array, so passing aApiPlatform\Metadata\QueryParameter(or any otherMetadata\Parameter) was silently accepted and only blew up much later insideOpenApiFactory::hasParameter()with an opaqueCall to undefined method ApiPlatform\Metadata\QueryParameter::getName().This patch guards
OpenApiFactory::hasParameter()(the call site that actually triggers the failure) with aninstanceof Parametercheck and throwsApiPlatform\Metadata\Exception\InvalidArgumentExceptionnaming the offending class and pointing the user at the resource-levelparametersoption used forMetadata\Parameterinstances.Why guard at the consumption site, not coerce
The two
Parameterclasses (Metadata\Parameter,OpenApi\Model\Parameter) live in different namespaces with no inheritance link and incompatible APIs (getKey()vsgetName()). Coercing one into the other would hide misuse, lose information (default schema fabrication, ambiguousininference, merge order withgetOpenApi()), and entrench the trap. A clear exception at the point of use teaches correct usage and matches the existing PHPDoc.Reproduction
Before: opaque
undefined method getName()deep inOpenApiFactory.After:
ApiPlatform\Metadata\Exception\InvalidArgumentExceptionnamingQueryParameterand directing to the resource-levelparametersoption.Test plan
OpenApiFactoryTest::testMetadataParameterInOpenApiOperationParametersThrowscovers the rejection path.OpenApitests still pass (one unrelated pre-existing failure ontestInvokeabout a 422 response description, present on the base commit).Fixes #8182