Unable to find "App\Entity\Role" entity identifier associated with the UnitOfWork #7103

New Issue

admin · 2026-01-22T15:44:42+01:00

admin commented

2026-01-22 15:44:42 +01:00

Originally created by @specdrum-agc on GitHub (Jan 30, 2023).

Bug Report

Unable to find "App\Entity\Role" entity identifier associated with the UnitOfWork

Q	A
BC Break	no
Version	2.14.1

Summary

When I try to flush changes in one Entity, that related to deleted one, exception is thrown.

Current behavior

Somewhat works wrong when deleting ManyToMany relation and saving related entity after flushing these changes.

I investigated the problem and found out that removing entity inside of method computeAssociationChanges does not detect such changes and collection stays dirty.

How to reproduce

https://github.com/specdrum-agc/doctrine-bug (See Readme)

The main part of test case

        $role = $this->doctrine->getRepository(Role::class)->find(1);
        $user = $role->getUsers()->current();
        $user->setName('test');

        // Need for collection initialization
        $roles = $user->getRoles()->toArray();
        $entityManager->remove($role);
        $entityManager->flush();

        // Second flush fails
        $entityManager->flush();

The test case might be strange, but I have similar behavior in real application. I have second flush in different part of application than first.

Expected behavior

Second flush call do not throw exception.

Originally created by @specdrum-agc on GitHub (Jan 30, 2023). ### Bug Report Unable to find "App\Entity\Role" entity identifier associated with the UnitOfWork | Q | A |------------ | ------ | BC Break | no | Version | 2.14.1 #### Summary When I try to flush changes in one Entity, that related to deleted one, exception is thrown. #### Current behavior Somewhat works wrong when deleting ManyToMany relation and saving related entity after flushing these changes. I investigated the problem and found out that removing entity inside of method `computeAssociationChanges` does not detect such changes and collection stays dirty. #### How to reproduce https://github.com/specdrum-agc/doctrine-bug (See Readme) The main part of test case ``` $role = $this->doctrine->getRepository(Role::class)->find(1); $user = $role->getUsers()->current(); $user->setName('test'); // Need for collection initialization $roles = $user->getRoles()->toArray(); $entityManager->remove($role); $entityManager->flush(); // Second flush fails $entityManager->flush(); ``` The test case might be strange, but I have similar behavior in real application. I have second flush in different part of application than first. #### Expected behavior Second `flush` call do not throw exception.

admin closed this issue

2026-01-22 15:44:42 +01:00

admin commented

2026-01-22 15:44:43 +01:00

@mpdude commented on GitHub (Jan 30, 2023):

So you change the user that it has to be flushed, but the roles association still contains the role that has been deleted?

@mpdude commented on GitHub (Jan 30, 2023): So you change the user that it has to be flushed, but the `roles` association still contains the role that has been deleted?

admin commented

2026-01-22 15:44:43 +01:00

@specdrum-agc commented on GitHub (Jan 31, 2023):

No, it doesn't. Only in collection's snapshot.
This is the point that state of collection comes into invalid state. When second flush in progress, UnitOfWork sees that and try to persist that change, but it was persisted in first flush.

@specdrum-agc commented on GitHub (Jan 31, 2023): No, it doesn't. Only in collection's snapshot. This is the point that state of collection comes into invalid state. When second flush in progress, UnitOfWork sees that and try to persist that change, but it was persisted in first flush.

admin commented

2026-01-22 15:44:44 +01:00

@mpdude commented on GitHub (Jan 31, 2023):

Did this work in previous ORM versions?

@mpdude commented on GitHub (Jan 31, 2023): Did this work in previous ORM versions?

admin commented

2026-01-22 15:44:44 +01:00

@specdrum-agc commented on GitHub (Jan 31, 2023):

I had 2.11.3 version installed, there was the same issue.

@specdrum-agc commented on GitHub (Jan 31, 2023): I had 2.11.3 version installed, there was the same issue.

admin commented

2026-01-22 15:44:44 +01:00

@mpdude commented on GitHub (Jan 31, 2023):

I am not sure what the expected behaviour would be, but #10485 provides a failing test for the time being.

@mpdude commented on GitHub (Jan 31, 2023): I am not sure what the expected behaviour would be, but #10485 provides a failing test for the time being.

admin commented

2026-01-22 15:44:44 +01:00

@specdrum-agc commented on GitHub (Jan 31, 2023):

@mpdude Thank you very much for adding test case for this issue! It reproduces the mentioned behavior. But looks like you are left excess comma on line 20. Test log says about it.

@specdrum-agc commented on GitHub (Jan 31, 2023): @mpdude Thank you very much for adding test case for this issue! It reproduces the mentioned behavior. But looks like you are left excess comma on line 20. Test log says about it.

admin commented

2026-01-22 15:44:44 +01:00

@mpdude commented on GitHub (Jan 31, 2023):

#10486 might be a fix

@mpdude commented on GitHub (Jan 31, 2023): #10486 might be a fix

admin commented

2026-01-22 15:44:45 +01:00

@mpdude commented on GitHub (Feb 15, 2023):

Duplicate: #10060

@mpdude commented on GitHub (Feb 15, 2023): Duplicate: #10060

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7103