Cannot modify readonly property Doctrine\ORM\EntityManager::$conn #54228
Comments
|
Hello, Same error in #54228. Any way related ? |
|
@NeilPeyssard You're referencing this issue. You meant another issue? |
|
Oups... Monday morning... Here is the issue: #54104 |
|
Yes and no. It seems like the reporter of the other issue avoided the trigger of issue, but didn't not resolve the real problem. I can't see how the fix has anything to do with the exception. In my case, I was able to reduce the number of exceptions by being a bit more cautious. I have replaced this listener public function onTerminate(TerminateEvent $event): void
{
if ($this->entityManager->isOpen()) {
$this->entityManager->clear();
$connection = $this->entityManager->getConnection();
while ($connection->isTransactionActive()) {
$connection->rollBack();
}
}
}by this public function onTerminate(TerminateEvent $event): void
{
$entityManager = $this->entityManager;
if ($entityManager instanceof LazyObjectInterface && !$entityManager->isLazyObjectInitialized()) {
return;
}
if ($entityManager->isOpen()) {
$entityManager->clear();
$connection = $entityManager->getConnection();
while ($connection->isTransactionActive()) {
$connection->rollBack();
}
}
}It was the more frequent place it failed ( |
|
The exception when using messenger could be solved in the same way: first check if the lazy object is initialized before checking if it's open. It is not a solution for my first example, where it fails in a HTTP request though. |
|
It seems heavily correlated with database errors impacting the doctrine entity manager. I have found the same pattern in processing of my message handlers. First a unique constraint error, then this readonly error. |
|
I was able to reproduce it reliably. class TestMessage
{
}.. and a message handler that tries to create an incomplete entity #[AsMessageHandler]
readonly final class TestMessageHandler
{
public function __construct(private EntityManagerInterface $entityManager, private LoggingService $loggingService)
{
}
public function __invoke(TestMessage $message): void
{
$user = $this->entityManager->find(User::class, 1);
Assertion::notNull($user);
$this->loggingService->logEvent('Automated cleanup');
$artist = new Artist('Elton John', Artist::TYPE_PERSON, $user);
$this->entityManager->persist($artist);
$this->entityManager->flush();
}
}I trigger it async framework:
messenger:
failure_transport: failed
transports:
async: '%env(MESSENGER_TRANSPORT_DSN)%'
failed: 'doctrine://default?queue_name=failed'
routing:
'App\Message\TestMessage': asyncIn the messenger output you can see that the error occurs on the first retry: |
|
I tried to fix it but unfortunately it's way above my skills 😄 Something is happening during the services resetting, and as you said, when the connection was closed, an error is thrown and the worker stops. Not really sure, but it may be a Doctrine bug (e.g. not a Symfony issue). I have created a reproducer for those who have an idea about what is wrong here. |
|
Should I already log this at Doctrine so they can have a look at it too? I think it's not a pure Symfony or Doctrine bug, but rather how they work together (and therefore rather a Symfony issue after all). |
|
Same problem with entityManager and messages... |
|
Running into the same issue with long lived Messenger worker processes after upgrade to ORM 3. The lazy ghosts are reset between messages and reinstating them causes it to crash. Line 114 of the Entity Manager is the constructor: I'm also not really sure if this is an issue with how the lazy ghosts work or how Doctrine uses them for this, I have no issue with other services. It seems to be a quite fundamental oversight in how lazy ghosts manually invoke the constructor on a living object but didn't really dive into it yet. |
|
Got the same error when calling resetManager() when EntityManager is closed example repository use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
use Doctrine\Persistence\ManagerRegistry;
class ShortLinkRepository extends ServiceEntityRepository
{
public function __construct(private readonly ManagerRegistry $registry)
{
parent::__construct($this->registry, ShortLink::class);
}
public function create(ShortLink $entity): void
{
$this->checkEntityManager();
$this->getEntityManager()->persist($entity);
$this->getEntityManager()->flush();
}
private function checkEntityManager(): void
{
if ($this->getEntityManager()->isOpen()) {
return;
}
$this->registry->resetManager();
}
}trace |
|
I have the same issue when I upgrated ORM 2.19 to 3.1 and using Messenging with Scheduler. |
|
@mathieudz You have two problem first is
|
|
@KamikX That not-null violation is just a reproducer for this bug. I cannot guarantee that I never have such DB errors, so this bug will continue to occur. |
|
@mathieudz Sorry, you are right, I was only concentrating on solving my current problem in the code and didn't read the whole context. |
|
I see the same problem with Swoole Runtime. Steps to reproduce:
|
|
I have the same problem in a Symfony Worker (message consumer). |
|
Also running this error when trying to do this in Symfony: |
|
When debugging this error went way deeper than at first glance. The root cause, in my case, was an already existing incremental value on a sequence. I use PostgreSQL and I injected some rows manually, not knowing that Datagrip wouldn't auto-increment my IDs. Then using debug/verbose output in the console the message (through messenger:consume) was clearly visible. I hope this helps someone. |
|
I had the same issue. For me, I had an incorrect Doctrine mapping: a |
Symfony version(s) affected
7.0.5
Description
Running Symfony 7.0 on frankenphp, I have upgraded to Doctrine ORM 3 and DBAL 4, and I intermittently get
Cannot modify readonly property Doctrine\ORM\EntityManager::$conn", which at first sight is pretty strange, because the constructor fails setting the initial value of$conn. Most probably, due toLazyGhostTrait.Example in an HTTP request:
Example in a MessageHandler:
How to reproduce
I have no idea how to reproduce it. It happens once in a while, seemingly random. E.g. a failed HTTP request will succeed afterwards, probably related to the usage of frankenphp.
UPDATE: It seems to happen in the request right after a request that closes the EntityManager, e.g. due to
Doctrine\\DBAL\\Exception\\UniqueConstraintViolationExceptionPossible Solution
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: