[HttpKernel] Add path to RequestPayloadValueResolver error message#64170
[HttpKernel] Add path to RequestPayloadValueResolver error message#64170HypeMC wants to merge 1 commit into
RequestPayloadValueResolver error message#64170Conversation
bf5a969 to
11353c6
Compare
cf34620 to
3039f14
Compare
3039f14 to
3c28c12
Compare
1f31c09 to
6a011e5
Compare
6a011e5 to
e39f20a
Compare
| "title": "Validation Failed", | ||
| "status": 404, | ||
| "detail": "filter: This value should be of type Symfony\\Bundle\\FrameworkBundle\\Tests\\Functional\\Filter.", | ||
| "detail": "filter: The value for argument \"filter\" should be of type Symfony\\Bundle\\FrameworkBundle\\Tests\\Functional\\Filter.", |
There was a problem hiding this comment.
I'm now seeing the failures on high-deps, which is when FWK 8.0 will run with HK 8.1
And then I realize: "filter: [...]" - this is already the arguments name.
and in the list of violations, we have "propertyPath": "filter"
which means: do we have anything to fix? if yes should we just add the path param for translations and keep the existing message?
There was a problem hiding this comment.
(or should we clean the "detail" prefix ;) )
There was a problem hiding this comment.
@nicolas-grekas The "filter: [...]" part is added by the ProblemNormalizer, meaning it's only shown when the normalizer is used. However, when the normalizer is not used, this information is not available. It's also not available in the logs.
As for the FWK 8.0 with HK 8.1 part, I'll fix this on lower branches.
There was a problem hiding this comment.
(or should we clean the "detail" prefix ;) )
Yes, i think that would make sense now.
Currently, when the
RequestPayloadValueResolveruses the Validator component, validation errors do not indicate which path the error refers to.For example:
{ "name": "Name", "age": "23", "active": "false" }Current validation errors:
These messages are difficult to understand because they do not indicate which field caused the violation.
However, when the Validator component is not available, the error messages are much clearer:
I'm submitting this as a bug fix because the current validator-based messages are not very useful in practice.