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

Aperta
  • Qualcosa non va?
#8,815 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
66/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
php, symfony
Ambito
backend-api-design

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
PHP
Stelle
2.6k
Fork
988
Merge medio
4g 10h
PR unite (30g)
114

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di api-platform/core

Tutte le issue di api-platform/core

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.