we came across the same problem at Pimcore

@ostrolucky

I installed a fresh Symfony 7.1.10 locally and required symfony/serializer-pack.

My composer.json file looks like this:

"require": {
    "php": ">=8.2",
    "ext-ctype": "*",
    "ext-iconv": "*",
    "phpdocumentor/reflection-docblock": "^5.6",
    "phpstan/phpdoc-parser": "^2.0",
    "symfony/console": "7.1.*",
    "symfony/dotenv": "7.1.*",
    "symfony/flex": "^2",
    "symfony/framework-bundle": "7.1.*",
    "symfony/property-access": "7.1.*",
    "symfony/property-info": "7.1.*",
    "symfony/runtime": "7.1.*",
    "symfony/serializer": "7.1.*",
    "symfony/yaml": "7.1.*"
}

The reason why you get a type mismatch here is because eventually, the code execution ends up in the extract method of the Symfony\Component\PropertyInfo\PropertyInfoExtractor to fetch the type of the attributes property. Here, we have the following $extractors in this order:

1. Symfony\Component\PropertyInfo\Extractor\PhpStanExtractor;
2. Symfony\Component\PropertyInfo\Extractor\PhpDocExtractor;
3. Symfony\Component\PropertyInfo\Extractor\ReflectionExtractor.

You can check the order by running bin/console debug:container --tag=property_info.type_extractor:

Service ID                           Priority                                                   
 ------------------------------------ ----------
  property_info.phpstan_extractor      -1000     
  property_info.php_doc_extractor      -1001    
  property_info.reflection_extractor   -1002

Since you are using the @var list<string> annotation for your property it means that the Symfony\Component\PropertyInfo\Extractor\PhpStanExtractor class can extract its type (array) and the remaining extractors are ignored. Later, the array type returned here is compared to the given string type. Since we no longer disable type enforcement by default we get the error you mentioned.

If we remove the annotation then we get the following behavior:

1. Symfony\Component\PropertyInfo\Extractor\PhpStanExtractor returns null;
2. Symfony\Component\PropertyInfo\Extractor\PhpDocExtractor returns null;
3. Symfony\Component\PropertyInfo\Extractor\ReflectionExtractor returns string as the property type because it infers it from the constructor (see the getType method in Symfony\Component\PropertyInfo\Extractor\ReflectionExtractor).

Depending on your context, the solutions are the following:

• manually set disable_type_enforcement to true when using MapQueryString in the controller;
• provide the query parameter as an array: ?attributes[]=displayName&attributes[]=userName;
• remove the @var annotation from the attributes property;
• disable the PhpStanExtractor or change the priorities but I am not sure what is the impact of such a change and I wouldn't do it unless I am fully informed about the consequences;
• some other options that I might have missed. However, I don't see an issue in the current behavior given that in the context you described we are enforcing types, we specify that the property is an array and then provide a string via the query parameter.

Thanks for detailed explanation!

I don't see an issue in the current behavior given that in the context you described we are enforcing types, we specify that the property is an array and then provide a string via the query parameter.

Well issue I see is that for successful denormalization, attributes query parameter has to match type in constructor, not a type of class property. From what you wrote, it seems PhpStanExtractor incorrectly extracts type of class property instead of class element that's actually going to be used for denormalization (constructor parameter). If it did extract type of constructor parameter, validator would realize that it is string, so same as query parameter.

Indeed. The Symfony\Component\PropertyInfo\Extractor\PhpStanExtractor checks the doc block of the property or of the accessor or mutator methods related to the property. It does not look into the constructor. The Symfony\Component\PropertyInfo\Extractor\ReflectionExtractor class does. I can't really tell whether this is an issue or intended behavior.

Maybe @Korbeil can shed some light here.

We're seeing the same issue in 6.4. Our workaround for now has been to rename the class property so it doesn't have the same name as the constructor argument, e.g.:

readonly class ScimQueryInput
{
    /** @var list<string> */
    private array $attributesArray;

    public function __construct(string $attributes = '') {
        $this->attributesArray = $attributes ? explode(',', $attributes) : [];
    }