Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[HttpKernel] Add path to RequestPayloadValueResolver error message#64170

Open
HypeMC wants to merge 1 commit into
symfony:8.1from
HypeMC:add-path-to-message
Open

[HttpKernel] Add path to RequestPayloadValueResolver error message#64170
HypeMC wants to merge 1 commit into
symfony:8.1from
HypeMC:add-path-to-message

Conversation

@HypeMC
Copy link
Copy Markdown
Member

@HypeMC HypeMC commented May 9, 2026

Q A
Branch? 8.1
Bug fix? no
New feature? no
Deprecations? no
Issues -
License MIT

Currently, when the RequestPayloadValueResolver uses the Validator component, validation errors do not indicate which path the error refers to.

For example:

final readonly class TestDTO
{
    public function __construct(
        public string $name,
        public int $age,
        public bool $active,
    ) {
    }
}
{
    "name": "Name",
    "age": "23",
    "active": "false"
}

Current validation errors:

This value should be of type int.
This value should be of type bool.

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:

The type of the "age" attribute for class "App\DTO\TestDTO" must be one of "int" ("string" given).
The type of the "active" attribute for class "App\DTO\TestDTO" must be one of "bool" ("string" given).

I'm submitting this as a bug fix because the current validator-based messages are not very useful in practice.

Comment thread src/Symfony/Bundle/FrameworkBundle/Tests/Functional/ApiAttributesTest.php Outdated
@HypeMC HypeMC force-pushed the add-path-to-message branch 3 times, most recently from cf34620 to 3039f14 Compare May 9, 2026 20:32
Comment thread src/Symfony/Bundle/FrameworkBundle/Tests/Functional/ApiAttributesTest.php Outdated
@HypeMC HypeMC force-pushed the add-path-to-message branch from 3039f14 to 3c28c12 Compare May 11, 2026 12:09
@nicolas-grekas nicolas-grekas modified the milestones: 6.4, 8.1 May 11, 2026
@HypeMC HypeMC changed the base branch from 6.4 to 8.1 May 11, 2026 13:01
@HypeMC HypeMC requested a review from chalasr as a code owner May 11, 2026 13:01
@HypeMC HypeMC force-pushed the add-path-to-message branch 2 times, most recently from 1f31c09 to 6a011e5 Compare May 11, 2026 13:02
@HypeMC HypeMC force-pushed the add-path-to-message branch from 6a011e5 to e39f20a Compare May 11, 2026 13:04
"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.",
Copy link
Copy Markdown
Member

@nicolas-grekas nicolas-grekas May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(or should we clean the "detail" prefix ;) )

Copy link
Copy Markdown
Member Author

@HypeMC HypeMC May 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(or should we clean the "detail" prefix ;) )

Yes, i think that would make sense now.

@nicolas-grekas nicolas-grekas modified the milestones: 8.1, 8.2 May 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants