I'm afraid that this listener should be stateful and events should be dispatched on post flush event https://github.com/doctrine/doctrine2/blob/2.7/lib/Doctrine/ORM/UnitOfWork.php#L430 (because Doctrine's transaction may fall)

This PR is rebased and squashed

/cc @sroze

Thank you. I've updated the PR

Maybe @weaverryan could have a look?

@Nyholm can you squad and push again? We should have Travis & AppVeyer rebuilding this :)

Comments are squashed. I will create a PR to doctrine bundle right away

Nice feature! This should not be in 4.4 ?

What if we avoid leaking events and eliminate the getter on the entity?

public function dispatchEvents(callable $dispatcher): void
{
    $dispatcher($this->events);
    $this->events = [];
}

Hm. Callables makes the stack tree hard to follow.

@vudaltsov How would you configure an implementation like this to work with DI?

@Nyholm , this would be almost the same code you use:

private function collectEventsFromEntity(LifecycleEventArgs $message): void
{
    $entity = $message->getEntity();

    if (!$entity instanceof EntityMessageCollectionInterface) {
        return;
    }

    $entity->dispatchEvents(function (iterable $events): void {
        foreach ($events as $event) {
            $this->messageBus->dispatch($event, [new DispatchAfterCurrentBusStamp()]);
        }
    });
}

As you see, we only need one command method in this case, not query+command.

Also, what if we implement this as a middleware, so that we don't depend on Doctrine here? It could do the same thing as the subscriber after the doctrine_transaction middleware. It will operate on any message object, not on a Doctrine entity.

Im closing this in favor of #34310