Description
Symfony version(s) affected: ^v3.4.41, ^v4.4.9, ^v5.0.9
Description
Hello folks 👋
I'm bringing to you kind of edge case. Since v3.4.41(and upmerged releases) usage of Valid
constraint on simple form types (relating directly to the field instead of encapsulating another object) like ChoiceType, TextType, or IntegerType breaks property path resolution of other fields with a Valid
constraint. This happens only if a particular field passes validation, and another field is failing. Everything works as expected if both fields are valid or invalid. As a result, the error message cannot be displayed on the right field, though the form is still correctly validated.
To illustrate this issue, let's validate ReviewForm from Sylius. It contains 4 fields: rating, title, description, and author. Rating(for whatever reason) and author have defined 'constraints' => Valid()
. If one would submit an empty form, this is the result:
and the validator calls:
everything works as expected.
However, if the rating field would be filled, this is the current result:
and the validator calls:
As you can see, in the second example, children[author].data.email
is replaced with [author].data.email
, which cannot be mapped to the form.
How to reproduce
The bug is reproduced here: 053d8fb.
In the attached commit, only one test will fail with the following result:
Possible Solution
I assume there is one wrong if statement in FormValidator
, which be fixed. Nonetheless, I wasn't able to spot it.
Since I've fixed our build by removing the new Valid()
constraint, I'm not sure if I should commit more energy into it. I can help you with solving it if you find this particular problem worth solving and if you give me some guidance.
Additional context
The bug was introduced somewhere here: symfony/form@v4.4.8...v4.4.9, probably by this commit: symfony/form@48ec675
The problem may be solved on our end with the removal of probably unnecessary new Valid()
constraint.
I'm openining this issue, as it is affected by wrong configuration in the first place and I'm not sure if there is a point in fixing it. Nevertheless, the "wrong" configuration was working properly since November 2016 and since version 3.0.0 until version 4.4.9.