Declaring a filter via `Parameter` logs an exception

[ameotoko]

API Platform version(s) affected: 4.1.20

Description
When a Filter is added to an Operation as described in the docs here, each filter declaration logs an exception:

ManagerRegistry must be initialized before accessing it.

How to reproduce
The setup involves two API resources:

#[ApiResource]
class Event
{    
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

#[ApiResource(
    new GetCollection(
        parameters: [
            new QueryParameter(
                key: 'event',
                filter: new NumericFilter(),
                property: 'event.id'
            )
        ]
    ),
)]
class Media
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\ManyToOne]
    private ?Event $event = null;

[michaljusiega]

I got the same exception, for OrderFilter. Looks like any filter extended with AbstractFilter may cause that exception.

parameters: new Parameters(
    parameters: [
        'order[:property]' => new QueryParameter(key: 'subject', filter: new OrderFilter(), property: 'subject', required: false),
    ]
)

I think QueryParameter::$filter should be narrowed down to OpenApiParameterFilterInterface, but for now allows for any FilterInterface instances.

[ameotoko]

To clarify: this doesn't affect functionality, the filters somehow work fine. Just log being spammed.

The docs also mention, that filter: argument actually accepts a service (which is why it throws in the first place, because doctrine is not being injected into constructor). If you set it to a real service id, e.g. api_platform.doctrine.orm.numeric_filter.instance, the exception goes away, but filter is ignored.

[soyuka]

Indeed we need to clarify a few things in the documentation old filters are not compatible using an instance (using new NumericFilter), only the filters from this PR are supported like this: #7121.

Using the service name should work especially with the ones suffixed by .instance. The dot notation is not supported though property: 'event.id' in fact it should be an IriFilter or an ExactFilter from #7121 (in the mean time use a SearchFilter using the service name) or even better create your own filter.

[ameotoko]

I still can't get it to work, using both official methods described in the docs. 🤔

I tried this:

services:
    media.event_filter:
        parent: 'api_platform.doctrine.orm.numeric_filter'
        arguments: [{ event: ~ }]
        autowire: false
        autoconfigure: false

#[ApiResource(
    operations: [
        new GetCollection(
            parameters: [
                new QueryParameter(
                    key: 'event',
                    openApi: new Parameter('event', 'query', description: 'Filter by event', schema: ['type' => 'integer']),
                    filter: 'media.event_filter',
                )
            ]
        )
    ]
)]

and this:

#[ORM\ManyToOne]
#[ApiProperty]
#[ApiFilter(SearchFilter::class, properties: ['event.id' => 'exact'])]
private ?Event $event = null;

Strangely, the simplest and most efficient way is still the "incompatible" one, by using new NumericFilter().

[ameotoko]

Actually, I'm being wrong – I realized that the identifier in ApiPLatform context will be an IRI, not the numerical ID. So, after adjusting my tests to use IRIs as parameter values, the SearchFilter worked as expected with both types of declarations mentioned in my previous comment (I also forgot to tag the service in yaml as api_platform.filter).

However, now my openApi: override is being ignored. Any thought on what might be wrong here?

[soyuka]

If you only want these changes you could instead:

new QueryParameter(
    key: 'event',
    description:  'Filter by event',
    schema: ['type' => 'integer'],
    filter: 'media.event_filter',
)

But if its the case please tell me if the openapi docs looks like it comes from the Filter (its possible that with these old filters we've a bug but its probably for backward compatibility we need to use the filter's getDescription, though I agree it'd be better to take our input on the parameter).

[ameotoko]

No, this configuration is being ignored too. Also, in both cases parameter is shown to be accepted as a string AND string[], which is not a big a deal, but not very clean documentation either...

[ameotoko]

When the filter is configured as a service, the SwaggerUI info seems to be coming from FilterInterface::getDescription() method.

core/src/Doctrine/Common/Filter/SearchFilterTrait.php

Lines 83 to 96 in 9e382e0

	$filterParameterNames = [
	$propertyName,
	$propertyName.'[]',
	];
	foreach ($filterParameterNames as $filterParameterName) {
	$description[$filterParameterName] = [
	'property' => $propertyName,
	'type' => 'string',
	'required' => false,
	'strategy' => self::STRATEGY_EXACT,
	'is_collection' => str_ends_with((string) $filterParameterName, '[]'),
	];
	}

description, openapi and schema are actually missing from the returned data, although they are described in the docs:

core/src/Metadata/FilterInterface.php

Lines 26 to 46 in 9e382e0

	* Returns an array with the filter parameter names as keys and array with the following data as values:
	* - property: the property where the filter is applied
	* - type: the type of the filter
	* - required: if this filter is required
	* - description : the description of the filter
	* - strategy: the used strategy
	* - is_collection: if this filter is for collection
	* - openapi: additional parameters for the path operation in the version 3 spec,
	* e.g. 'openapi' => ApiPlatform\OpenApi\Model\Parameter(
	* description: 'My Description',
	* name: 'My Name',
	* schema: [
	* 'type' => 'integer',
	* ]
	* )
	* - schema: schema definition,
	* e.g. 'schema' => [
	* 'type' => 'string',
	* 'enum' => ['value_1', 'value_2'],
	* ]
	* The description can contain additional data specific to a filter.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[VincentLanglet]

Hi @soyuka

I also have the error ManagerRegistry must be initialized before accessing it.
The filter was declared this way

new GetCollection(
            parameters: [
                'live' => new QueryParameter(filter: new BooleanFilter(), property: 'live'),
            ],
        ),

to filter list based on live property (which is a boolean).

It works fine this way but if I understand the explanation here:

• it's the reason of the log
• it's not supposed to be used this way.

While the #[ApiFilter attribute was easy to use, I still didn't correctly understand the right way to migrate the filter...
So how should be written

new GetCollection(
            parameters: [
                'live' => new QueryParameter(filter: new BooleanFilter(), property: 'live'),
            ],
        ),

?

I also tried api_platform.doctrine.orm.boolean_filter.instance but it doesn't work.
When I use debug:container I get

 The "api_platform.doctrine.orm.boolean_filter.instance" service or alias has been removed or inlined when the 
 !        container was compiled.

this is maybe the reason

[vinceAmstoutz]

Perhaps we should reopen this issue @soyuka