Multiple ValidationContext : Wrong Swagger documentation

[Piairre]

API Platform version(s) affected: 3.2.13

Description
When multiple validationContext are used on the same property, the Swagger documentation is incorrectly generated; it utilizes the same Assert regardless of the validationContext .
The validation works correctly during the API call, it's just the Swagger documentation generation that is incorrect.

How to reproduce
Using Validation documentation :

<?php
// api/src/Entity/Book.php

use ApiPlatform\Metadata\ApiResource;
use ApiPlatform\Metadata\Delete;
use ApiPlatform\Metadata\Get;
use ApiPlatform\Metadata\Put;
use ApiPlatform\Metadata\GetCollection;
use ApiPlatform\Metadata\Post;
use ApiPlatform\Metadata\ApiResource;
use Symfony\Component\Validator\Constraints as Assert;

#[ApiResource]
#[Delete]
#[Get]
#[Put(validationContext: ['groups' => ['Default', 'putValidation']])]
#[GetCollection]
#[Post(validationContext: ['groups' => ['Default', 'postValidation']])]
class Book
{
    #[Assert\Uuid]
    private $id;

    #[Assert\NotBlank(groups: ['postValidation'])]
    public $name;

    #[Assert\NotNull]
    #[Assert\Length(min: 2, max: 50, groups: ['postValidation'])]
    #[Assert\Length(min: 2, max: 70, groups: ['putValidation'])]
    public $author;

    // ...
}

Here is the generated documentation for the 'author' property for both the POST and PUT methods:

[soyuka]

indeed serialization groups are handled but validation not, feel free to patch that looking at how we did with serialization groups (in the schema factory).

[Piairre]

I was able to work on a solution, but I'm not completely satisfied with what I'm proposing, and I think there's a cleaner way to achieve this.

I modified the way $definitionName is generated; I concatenated it with the validation groups (in addition to the serialization groups). Using the code example above, definitions look like this :

Address.jsonld-Default_putValidation
Address.jsonld-Default_postValidation

The two schemas are separated, and the documentation becomes valid. But I'm not sure if renaming definitions is the best solution...

@soyuka, any thoughts on this?