QueryParameter with custom constraints results in error "This value should be of type string."

[Jontsa]

API Platform version(s) affected: 4.1.9

Description

Upgrading to api-platform/core 4.1.9 breaks query parameters with custom constraints that worked with 4.1.8. It looks like it is caused by PR #7134. QueryParameter with custom constraint results in "This value should be of type string." error unless you add the new nativeType parameter.

How to reproduce

#[ApiResource(
    operations: [
        new GetCollection(
            provider: MyProvider::class,
            parameters: [
                'country' => new QueryParameter(schema: ['type' => 'string'], constraints: [new Country()]),
            ],
        ),
    ],
)]
final readonly class MyResource
{
}

To make it work again, you need to remove constraints -parameter or add nativeType parameter: new Type\BuiltinType(TypeIdentifier::STRING).

Possible Solution

Additional Context

[soyuka]

Yes this is expected as things were inconsistent before that.

[Jontsa]

Warning of a breaking change might be a good idea in that case.

Having string as the default type could also be a good idea.

[nesl247]

Even without custom constraints, using enum in the schema is broken without adding the nativeType. I'm not sure why it doesn't get the type from the type. If the type is string in the schema, then it's a string, not an array of strings. The default should be string IMO.

[soyuka]

The parameter feature is experimental, also parameters default to array because foo[]=bar is always parsed in PHP (same for HTTP arrays they default to arrays). Indeed we could infer types from the schema but this will lead to the same inconsistencies see #7111.

By the way the default type is string|string[] what's the value you sent @Jontsa ?

[Jontsa]

By the way the default type is string|string[] what's the value you sent @Jontsa ?

curl -X 'GET' \
  'https://localhost:8443/my_resources?country=FI' \
  -H 'accept: application/ld+json'

{
  "@context": "/contexts/ConstraintViolation",
  "@id": "/validation_errors/00000000000021430000000000000000",
  "@type": "ConstraintViolation",
  "status": 422,
  "violations": [
    {
      "propertyPath": "country",
      "message": "This value should be of type string.",
      "code": null
    }
  ],
  "detail": "country: This value should be of type string.",
  "description": "country: This value should be of type string.",
  "type": "/validation_errors/00000000000021430000000000000000",
  "title": "An error occurred"
}

[soyuka]

I thought I could avoid using a flag for this but I guess it makes more sense like this.

@nesl247 we can maybe discuss this in another issue?

Even without custom constraints, using enum in the schema is broken without adding the nativeType. I'm not sure why it doesn't get the type from the type. If the type is string in the schema, then it's a string, not an array of strings. The default should be string IMO.

I need to infer the type from the schema I'll add another patch for this. I focus to much on the backward compatibility of filters and therefore I didn't thought about this.