fix(validator): do not emit an unresolved {{ type }} placeholder - #8546
Merged
Merged
Conversation
A normalizer can report no expected type while carrying a user-facing message
that lists what it accepts: that is what Symfony's BackedEnumNormalizer does.
When the property also carries a constraint, emitViolation() skipped the
verbatim branch and fell back to the generic Type message, whose "{{ type }}"
placeholder then had nothing to be filled with and reached the client as-is:
condition: This value should be of type {{ type }}.
Use the exception message when the placeholder cannot be resolved. Only the
rendered message changes: the message template, the code, the parameters and
the constraint are left untouched, so violations keep grouping and translating
on the same template. The rule table documented on the class is unchanged, and
the branch is unreachable when expected types are known.
Member
|
thanks! |
vincentchalamon
added a commit
to api-platform/demo
that referenced
this pull request
Sep 26, 2026
5.0.1 carries the two fixes this branch was waiting on: - api-platform/core#8546 resolves the "{{ type }}" placeholder, so the four validation failures are gone and the suite is green. - api-platform/core#8537 widens api-platform/test to allow phpunit ^13.0. The constraint here was already widened in anticipation, so composer picked 13.3.5 on its own. Mercure 1.0.2 also landed, and it now allows only one *unnamed* hub per configuration. SERVER_NAME holds two addresses (the public one and php:80 for internal calls), so Caddy builds two servers and instantiates the handler twice, which made the container fail to boot. Naming the hub is enough; the name only feeds the health check endpoint and the metrics.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A normalizer can report no expected type while carrying a user-facing message that lists what it accepts: that is what Symfony's BackedEnumNormalizer does. When the property also carries a constraint, emitViolation() skipped the verbatim branch and fell back to the generic Type message, whose "{{ type }}" placeholder then had nothing to be filled with and reached the client as-is:
Use the exception message when the placeholder cannot be resolved. Only the rendered message changes: the message template, the code, the parameters and the constraint are left untouched, so violations keep grouping and translating on the same template. The rule table documented on the class is unchanged, and the branch is unreachable when expected types are known.