Filter is not properly set

[Webonaute]

Filter are not injected into instance of entity manager when using MyRepository extend ServiceEntityRepository, with

public function __construct(RegistryInterface $registry)
    {
        parent::__construct($registry, MyEntity::class);
    }

In FilterCollection.php line 107:

[InvalidArgumentException]
Filter 'softdeleteable' does not exist.

[mwansinck]

@Webonaute Did you find a solution? I am getting the same issue after adding symfony/flex to a Symfony 3.4 project (however the symfony/flex part could be unreleated)

[Webonaute]

We did a pr about it, by we I mean my coworker. Will follow up with the status later today.

[mwansinck]

@Webonaute Could you provide me with the follow up please :-)

[Webonaute]

Sorry, I can't find what we did... :/ @supersmile2009 do you remember?

[Webonaute]

here is some patch we use for Softdelete.

 "fix softdeletable query cache": "https://github.com/Atlantic18/DoctrineExtensions/commit/ef5ceb8d212a2625b171cb1dc5ed31af901dd5e2.patch",
"various improvements in softdeletable": "https://github.com/supersmile2009/DoctrineExtensions/commit/0e26c0cefd50f8084a16cad240f613414e1a02df.patch",
"use closures instead of reflection": "https://github.com/supersmile2009/DoctrineExtensions/commit/c485aada9a74aa2a44ba52f82c63c4d5ecc2679e.patch"

[mwansinck]

@Webonaute Thanks, I am going to try this anytime soon.

[Anyqax]

This happened for us as well after updating to symfony 3.4 in the following scenario:

an EntityListener, which is not lazy loaded
the softdeleteable extension

What seems to be happening is:

during the instantiation of a repository service, the listener service instantiation (getDoctrine_Orm_DefaultEntityListenerResolverService) is triggered even before the orm configuration (which includes the filters) has been properly completed... that's why the entity manager (as part of the listener service instantiation) is instantiated without filters (and every other configuration option which comes after the listener service instantiation).
Using the lazy load option for the entity listener does circumvent the problem.

What seems to fix this without the lazy load option is to move the filter initialisation

DoctrineBundle/DependencyInjection/DoctrineExtension.php

Line 450 in ad278ef

$enabledFilters = [];

before the listener initialisiation

DoctrineBundle/DependencyInjection/DoctrineExtension.php

Line 430 in ad278ef

foreach ($methods as $method => $arg) {

. This is probably necessary for the "hydrators" and "dql" configuration options as well.

This is the problematic service initialisation logic in the generated container:

protected function getDoctrine_Orm_DefaultConfigurationService()
{
    ...
    $instance->setEntityListenerResolver(${($_ = isset($this->services['doctrine.orm.default_entity_listener_resolver']) ? $this->services['doctrine.orm.default_entity_listener_resolver'] : $this->getDoctrine_Orm_DefaultEntityListenerResolverService()) && false ?: '_'});
    $instance->setRepositoryFactory(new \Doctrine\Bundle\DoctrineBundle\Repository\ContainerRepositoryFactory(new \Symfony\Component\DependencyInjection\ServiceLocator(array('AppBundle\\Entity\\DuplikatsKandidatRepository' => function () {
        return ${($_ = isset($this->services['AppBundle\Entity\DuplikatsKandidatRepository']) ? $this->services['AppBundle\Entity\DuplikatsKandidatRepository'] : $this->load('getDuplikatsKandidatRepositoryService.php')) && false ?: '_'};
    }))));
    $instance->addCustomStringFunction('replace', 'DoctrineExtensions\\Query\\Mysql\\Replace');
    $instance->addFilter('soft_deleteable', 'Gedmo\\SoftDeleteable\\Filter\\SoftDeleteableFilter');
}

Might also be related to #841

[supersmile2009]

Hi.
Somehow I missed the notification when I was tagged here :)

The cause of this issue is indeed the order of EntityManager initialization in DoctrineBundle/DependencyInjection/DoctrineExtension as mentioned by @Anyqax in comment above. My initial solution was to reorder some code in there, but we eventually moved on to lazy listeners and repositories because of #841.

If you don't use lazy listeners and repositories and try to inject a repository as a service into a listener you also end up with 2 instances of EntityManager, thus detached entity issues mentioned in #841. Entities are not really detached, they are just attached to a wrong EntityManager instance.
I'm pretty sure that lazy services is the only proper solution in this case, since we're dealing with a circular dependency (EntityManager instantiates listeners, which require Repository. Repository requires an EntityManager and instantiates a new manager)

Since Symfony 4.2 listeners are always lazy which automatically solves this issue.
symfony/symfony#27675
If you're not on 4.2, just make your listeners and repositories lazy through config.

[alcaeus]

Closing here for the same reason as #841 (comment).