Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
[Serializer] Improve nested payload validation for#[MapRequestPayload]
using a new serialization context#53250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:7.4
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
carsonbot commentedDec 28, 2023
Hey! Thanks for your PR. You are targeting branch "7.1" but it seems your PR description refers to branch "7.1 for features 6.3, 6.4, 7.0". Cheers! Carsonbot |
a25d919
to62d7c88
Compare#[MapRequestPayload]
using a new serialization context62d7c88
to55880a5
Compare…r MapRequestPayload using a new serialization context
55880a5
to988304e
Compare$arguments = $resolver->resolve($request, $argument); | ||
$event = new ControllerArgumentsEvent($kernel, function () {}, $arguments, $request, HttpKernelInterface::MAIN_REQUEST); | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
You can leverageexpectException
andexpectExceptionMessage
instead
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Hello everyone,
When validating anested object using MapRequestPayload, and given payload schema doesn't respect the DTO provided, Symfony serializer throws
PartialDenormalizationException
.Unfortunately the
MapRequestPayloadResolver
doesn't have enough information about the Dto structure to be able to provide a more detailed error, Instead symfony throws the errors "This value should be of type unknown."Thisunknown type is originated from the
AbstractNormalizer
in the serializer component, which injects this value toNotNormalizableValueException class.I propose to add new Serialization context
AbstractNormalizer::USE_CLASS_AS_DEFAULT_EXPECTED_TYPE
,which allows us to retrieve the class as the expected type for Our DTO if needed.
Example when using the context AbstractNormalizer::USE_CLASS_AS_DEFAULT_EXPECTED_TYPE:

I honestly do not know the reason behind using unkown instead of the FQCN. I find adding a new context more safe, and certainlyBackward compatible to support both usages.
Usage example in a controller:
https://github.com/mmouih/apps-demo/blob/19f9edfa4361567a4b592a32041ead327fb3b898/src/Controller/HomeController.php#L22,L28
I included tests for the new feature:
https://github.com/mmouih/symfony/blob/05ef92028cb75c556ebbf2857617bdf40b8f1643/src/Symfony/Component/HttpKernel/Tests/Controller/ArgumentResolver/RequestPayloadValueResolverTest.php#L288C21-L288C94
Best regards.