Looks like a bugfix to me, in this case 🎯6.3, but let's wait for advice of@nicolas-grekas

This would need tests for sure. But I'm no expert in the Serializer component so I'd appreciate if someone more familiar with it could review.

I've added tests. I also discovered that$builtinType isn't reset in the for-loop in some cases. Which means aObject|bool type wouldn't hit this switch-case:https://github.com/symfony/symfony/blob/6.4/src/Symfony/Component/Serializer/Normalizer/AbstractObjectNormalizer.php#L471 (The added tests also cover this).

Another interesting failure scenario:

// this fails$this->serializer->denormalize(['element' =>'0'], Example::class, context: [AbstractObjectNormalizer::DISABLE_TYPE_ENFORCEMENT =>true]);class Example {publicfunction__construct(publicArgs|int$element) {}}class Args {publicfunction__construct(publicUuid$nested,privatestring$test)}//  [Symfony\Component\Serializer\Exception\MissingConstructorArgumentsException]//  Cannot create an instance of "App\Args" from serialized data because its constructor requires the following parameters to be present : "$nested", "$test".// whereas this returns an instance succesfully$this->serializer->denormalize(['element' =>'0'], Test::class, context: [AbstractObjectNormalizer::DISABLE_TYPE_ENFORCEMENT =>true]);class Test {publicfunction__construct(publicUuid|int$element)}

Because the first denormalization throwsMissingConstructorArgumentsException, which goes before the return onDISABLE_TYPE_ENFORCEMENT.
The second throwsNotNormalizableValueException, but is caught and will return0 because ofDISABLE_TYPE_ENFORCEMENT.

I'm not sure what the reasoning was here or if this is actually not intended.

It could be fixed by adding$hasTypeMismatch = $builtinType !== Type::BUILTIN_TYPE_OBJECT here:
https://github.com/symfony/symfony/blob/6.4/src/Symfony/Component/Serializer/Normalizer/AbstractObjectNormalizer.php#L565. To establish that it did not throw for at least one of the$types.
And the later using that to return beforeMissingConstructorArgumentsException. (Or always return before that exception when DISABLE_TYPE_ENFORCEMENT is true?)

Let's resume this one? Is this a bugfix as it's documented in the PR description? If yes can you please target the lowest affected branch?

Applied feedback and targeting6.3

Isn't 5.4 affected also?

Eh yes, I was looking into the wrong part when checking that branch. Now based on 5.4.

Parse error on PHP 7.2 ;)

Serializer tests are ok now

(rebase needed ;) )

Thank you@Jeroeny.