Schema definition name uses a validation groups generator's service id as a literal group (since #8595)

Ouverte
  • Quelque chose ne va pas ?
#8,815 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
66/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
php, symfony
Domaine
backend-api-design

Piste de recherche

Start with JsonSchema\DefinitionNameFactory::getValidationGroupsPart() and compare its handling of a string group value with the validator behavior described in the issue. Reproduce by exporting OpenAPI with the shown generator service id in validationContext.groups; done when the definition name no longer includes that service id while its suffix agrees with the constraints used in the schema.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Q A
API Platform version(s) affected 4.4.6
Symfony 8.1.11
PHP 8.4
Description

Since #8595, DefinitionNameFactory appends an operation's validation groups to the JSON Schema definition name. When validationContext.groups is the service id of a validation groups generator (a string naming a service tagged api_platform.validation_groups_generator), the name factory treats that string as a literal group name. The service id ends up in the definition name.

The validator side handles the same value differently, so the name no longer describes the constraints in the schema:

Where What it does with 'groups' => BookGroupsGenerator::class
JsonSchema\DefinitionNameFactory::getValidationGroupsPart() (v4.4.6, line 112) Wraps the string in an array and flattens it, so the name gets validation.App.Validator.BookGroupsGenerator
Symfony\Validator\Metadata\Property\ValidatorPropertyMetadataFactory::getValidationGroups() (line 155) Uses validation_groups only when it is an array or a GroupSequence, so a string falls back to the class default group Default
Symfony\Validator\Validator::validate() (line 38) At runtime, resolves the service id from the container and calls it with the object

The docblock on getValidationGroupsPart() says it mirrors ValidatorPropertyMetadataFactory::getValidationGroups() "so a definition name and the constraints it labels always agree". For a service id they do not agree: the name claims the generator's groups, while the schema's constraints come from Default.

A group-provider callable is already skipped (\is_callable($groups) returns ''). A generator service id is just as dynamic, because only the validator can compute its groups. But it reaches the flattening code and becomes part of the name.

How to reproduce
use ApiPlatform\Metadata\ApiResource;
use ApiPlatform\Metadata\Post;
use Symfony\Component\DependencyInjection\Attribute\AutoconfigureTag;
use Symfony\Component\Serializer\Attribute\Groups;
use Symfony\Component\Validator\Constraints as Assert;

#[AutoconfigureTag('api_platform.validation_groups_generator')]
final class BookGroupsGenerator
{
    public function __invoke(Book $book): array
    {
        return ['Default', 'book:strict'];
    }
}

#[ApiResource(operations: [
    new Post(
        denormalizationContext: ['groups' => ['book:write']],
        validationContext: ['groups' => BookGroupsGenerator::class],
    ),
])]
class Book
{
    #[Groups(['book:write'])]
    #[Assert\NotBlank(groups: ['book:strict'])]
    public ?string $title = null;
}

Export the OpenAPI document (bin/console api:openapi:export) and look at the input definition for POST /books.

Expected

One of these:

  • A generator service id is handled like a callable: no validation suffix, because the groups are only known at validation time.
  • Or the name and the constraints are built from the same resolved groups.
Actual

The definition is named Book-book.write_validation.App.Validator.BookGroupsGenerator, and its constraints are built from the Default group. On 4.3 the name was Book-book.write, so every generated client renames the type on upgrade, and the new name describes groups the schema does not use.

Possible solution

In getValidationGroupsPart(), return '' for a string value that is not an array or GroupSequence. That matches ValidatorPropertyMetadataFactory, which ignores such a value and uses Default. A string that names a single static group would then lose its suffix as well. If that matters, the check could ask the container whether the string is a service id, the way Validator::validate() does.

Workaround

Pin the name with SchemaFactory::OPENAPI_DEFINITION_NAME in the operation's normalization and denormalization contexts. #8595 notes that the explicit override still wins.

Langage dominant
PHP
Étoiles
2.6k
Forks
985
Merge moyen
4 j 13 h
PR mergées (30 j)
117

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de api-platform/core

Toutes les issues de api-platform/core

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.