I think the main issue here is that the entity manager once closed cannot really be reopened (since Doctrine cannot guarantee that the entity state is consistent any more). AFAIK this is the root cause that forces resetService to be written in a way that creates a new EM, so that the user can always get a usable instance.

The problem here arises when the Manager - @doctrine.orm.default_entity_manager itself is injected to a service (instead of the ManagerRegistry - @doctrine), combined with an execution model like PHP-PM which does not clear everything at the end of the request. In this case, when the entity manager is reset, the services that had it injected directly do not know that their instance of the EM is no longer valid and will attempt to use the previous version. On the other hand, services that inject ManagerRegistry will return the new version when getManager is called, so in the end some services will be using one instance of the manager and others the other.

As long as Doctrine doesn't provide a way to cleanly reopen the existing entity manager (and basically ensuring that ManagerRegistry always provides the same instance of the EM), I personally can't think of a good solution to this other than discouraging users from setting the entity manager as a property in their services.

As you can see, this method is willing to break encapsulation with Closure::bind already, so I don't see why it can't just do clear() and force set the closed flag to false.

Also I don't really buy reasoning that doctrine closes entity manager because it can no longer guarantee entity state -> there is no entity state when error happens, because close does clear() first.

Apologies, I didn't realize Closure::bind was being used already. It does feel a bit hacky and I'm not really sure what kind of side-effects it could have, but I guess reopening it in this way would work.

I wonder though, is this maybe something deeper that should be addressed within Doctrine? If it's safe to reopen a closed EM after a clear, shouldn't Doctrine provide a reopen method or even just reopen the EM automatically when clear is called? This would make the bridge's job here so much easier.

Yes but that would be a new feature, while this is a bug. Bridge should first fix resetting in a way that does not break identities, doctrine itself can in future provide easier way to do it.

Would be great to understand what are the deeper implications in the ORM (if there are some, which is implied by reading the EM code comments) of reopening an EM. I always thought it was more of a DBAL thing, being unable to reopen the actual DB connections after a failure.

Injecting @doctrine.orm.default_entity_manager in a service is fine with resetting (except maybe in some weird cases triggering undetected circular references breaking the proper initialization, but then not only resetService will be affected).

The issue happens when you define an entity repository as a service without using the ServiceEntityRepository feature. this is a known issue. and that's why DoctrineBundle and Symfony said for years that Doctrine repositories should not be defined as services (and that's why we implemented ServiceEntityRepository to have a way to define them as services).

The always-working way to reopen an entity manager would require to be able to reopen the existing entity manager, which would require the ORM itself to have such feature (and I don't see that coming to a 2.x release).

@stof afaik with a Closure::bind you could reopen the EM without having to mess with the ORM, we're already "hacking" the proxy in the same way to reset it. So why not actually clear + reopen the same EM (it's basically just reverting the closed property of the EM)? What are the implications of doing it? Even the proxy wouldn't be needed anymore.

For reference, your issue in doctrine/orm#5933

For future reference once anyone has the same issue as I had:

class MyEntityServiceRepository
{
    /**
     * @var EntityManagerInterface
     */
    private EntityManagerInterface $entityManager;

    /**
     * @var ObjectRepository
     */
    private ObjectRepository $repository;

    public function __construct(EntityManagerInterface $entityManager)
    {
        $this->entityManager = $entityManager;
        $this->repository = $entityManager->getRepository(InternalTrack::class);
    }

When using this in a Symfony messenger setup. One of your jobs triggers an exception in the EntityManager which will close the entitymanager. You will run into very strange errors. Since on the second job your repository and entitymanager in this situation are not having the same UnitOfWork.

The way to fix this is not having a property for your repository, but fetch it on access from the entitymanager which is nicely reset.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

.

@carsonbot This is still relevant, yep!

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Friendly ping? Should this still be open? I will close if I don't hear anything.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

The workaround is similar to what has been described before:

The way to fix this is not having a property for your repository, but fetch it on access from the entitymanager which is nicely reset.

Of course it'd be better if we could have a working "reset" method on Doctrine's side.
Which makes me wonder: why do we need this issue on the Symfony repo?

Because the way how symfony resets em breaks identities. Argument that there is no support for it in orm doesn't stand considering symfony already uses closure:: bind to break through encapsulation.

this method is willing to break encapsulation with Closure::bind already

Closure:bind is used on an instance of the container, which is something that is in Symfony's responsibility area.

so I don't see why it can't just do clear() and force set the closed flag to false.

Because then we'd be crossing a responsibility boundary, namely doing something that is within Doctrine's area. /cc @acasademont also since you were wondering about why we don't use Closure::bind to hack into Doctrine's state.

Resetting this state should be done on Doctrine's side.

Closing as explained in favor of doctrine/orm#5933

Yep, makes sense to fix it upstream and then get rid of the nasty proxy hack in Symfony