Hello, I can try a PR during the #SymfonyHackday

The bug is introduce with #47128 and maybe already a fix with #50201
The #50192 don't also solve the issue

In these condition what is the best way to fix that ?

Instead of focusing on the Serializer, one could also catch and handle the Serializer's InvalidArgumentException in the RequestPayloadValueResolver. However I don't know if it was a deliberate choice not to catch the InvalidArgumentException already.

Maybe @Koc can chime in about that?

During the SymfonyHackday, after discussing with @dunglas and @nicolas-grekas , we explored two initial approaches to address this without making significant changes to the Serializer but by working at the level of the RequestPayloadValueResolver:

• Caught the Serializer's InvalidArgumentException at the RequestPayloadValueResolver level to convert the 500 error to a 422 error.
• Similarly, but replaced InvalidArgumentException with a new Exception class extending it for a more precise catch.

Upon delving deeper into the code, I then came across the concept of PartialDenormalizationException. The first two approaches do not allow for surfacing the error in the same way as for errors on other types of a DTO by returning a collection of violations. Having a consistent solution when COLLECT_DENORMALIZATION_ERRORS = true would be a plus IMO

I don't know what to do after reading this pull request: #50201

Hi!

I'd like to take over this issue!

If we have to choose between the two solutions above, then I'd go for the second one. Throwing a custom exception (that inherits from InvalidArgumentException) would allow us to store useful data so we can create a ConstraintViolation in RequestPayloadValueResolver (e.g. propertyPath, invalidValue, etc.)

However, I agree with @SebLevDev regarding the concept of PartialDenomalizationException... It is inconsistent.

@dunglas @nicolas-grekas : 5 months later, do you still think that catching the InvalidArgumentException on the RequestPayloadValueResolver level is the right solution? If so, I have time to work on it. 😉

Sorry, is there any final solution to this issue?

The current workaround I use:

class MyInputDTO
{
    /**
     * DO NOT REMOVE THAT, it's a workaround to a bug of the SF denormalizer that is using the type of the getter
     * @var string
     */
    #[Assert\NotBlank]
    #[Assert\Choice(callback: [MyEnum::class, 'values'])]
    public string $type;
    
     public function getType(): MyEnum
    {
        return MyEnum::from($this->type);
    }
}    
    
    
enum MyEnum: string
{
    case A = 'A ';
    case B = 'B';
    case C = 'C';

    public static function values(): array
    {
        return array_column(self::cases(), 'value');
    }
}

Thanks! Cool solution:)

up

From my previous comment

The current workaround I use:

class MyInputDTO
{
    /**
     * DO NOT REMOVE THAT, it's a workaround to a bug of the SF denormalizer that is using the type of the getter
     * @var string
     */
    #[Assert\NotBlank]
    #[Assert\Choice(callback: [MyEnum::class, 'values'])]
    public string $type;
    
     public function getType(): MyEnum
    {
        return MyEnum::from($this->type);
    }
}
[...]

I made some changes in my current usage:

class MyInputDTO
{
    #[Assert\NotBlank]
    #[Assert\Choice(callback: [MyEnum::class, 'values'])]
    public string $type;
    
    public function getTypeEnum(): MyEnum
    {
        return MyEnum::from($this->type);
    }
}

The suffix Enum on the getter allows me to remove the @var string on the property

I also encountered this problem, can you tell me if it will be solved by the framework?

I really would not like to remake all the code that uses enum to the option proposed by @alexandre-le-borgne