Would you be able to submit a failing test case?
Or maybe a small reproducer app?

@nicolas-grekas Yes. Here is a broken app : https://github.com/nykopol/broken-app
You just have to go to the default controller.
I noticed that this only occur if the listener depends on doctrine.orm.entity_manager.

@nykopol , you should not inject entity manager via constructor because that leads to a circular dependency. Listeners are "child" objects in relation to the manager, so they cannot receive it as a dependency.

Instead you should use the second argument of your callable to retrieve the relevant entity manager:

<?php

namespace AppBundle\Listener;

use AppBundle\Entity\MyEntity;
use Doctrine\ORM\Event\PreUpdateEventArgs;

class ServiceThatWillNotFailAnymore
{
    public function __construct(/* other args */)
    {
    }

    public function prePersist(MyEntity $entity, PreUpdateEventArgs $args)
    {
        $entityManager = $args->getEntityManager();
    }
}

I hope, that will solve your issue.

Btw, you can find more about the listener's arguments in the official Doctrine Documentation.

I think we should explain how to retrieve entity manager in the Doctrine Bundle's docs.

@javiereguiluz, @nicolas-grekas, WDYT?

@vudaltsov I understand the fact that Listener is a "child" object and that I can get the manager in the prePersist. But in real life, my Listener doesn't inject directly doctrine.orm.entity_manager but an other service which inject it.

For the principle, a Listener is a service. Why he's not allowed to inject this service ? We can imagine a use case where the listener collect some information on prePersist and the persist something at kernel.finish_request. It would require the entity manager.

Circular dependency is a bad practice 99% of the time, no matter how long the dependency chain is. As a rule it points at some architectural problems.

In your case I see the problem of mixing different contexts. The context of the entity manager transaction and the request context. Here you can create a separate service called SomeCollection with add(Type $item): void and all(): iterable|Type[] methods. It will be responsible for collecting and providing information in different contexts: you will inject SomeCollection into your SomeEntityPrePersistListener (and probably some other services) for collecting info and into OnFinishRequestListener for actually using it. OnFinishRequestListener will also inject entity manager to do entity-related stuff.

While my solution is still not ideal and might be improved for your particular case, it uses a mediator object (see Indirection in GRASP) to organize communication between services and to eliminate the circular dependency problem.

thanks for the help