[PR #10874] Emit postFlush events as the very last thing in UoW::flush() #12671

New Issue

admin · 2026-01-22T16:14:48+01:00

admin commented

2026-01-22 16:14:48 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/10874

State: closed
Merged: No

This PR moves the postFlush event dispatching after final clean-up steps in UnitOfWork::commit().

The idea is that at this time, commit() is "as done as it gets", and it might be possible to call EntityManager::flush() again from event listeners – we'd return from that method on the very next line, and everything would be in the same state if users dediced to call flush() again themselves.

Obviously, infinite recursion is one thing either the ORM or users would need to think about.

The intent is to make it somehow possible for users to have event listeners that get notified e. g. through postPersist to prepare "cascading" changes. These changes could be collected and applied in a postFlush listener, which might then call flush() again.

This sparked off from #10869, where the reporting user is calling flush() even from postPersist – a questionable practice, probably never endorsed but it "somehow worked" until 2.16.0.

⚠️ BC Break: If postFlush listeners inspect UoW state through methods like isSchedulesForInsert or getEntityChangeSet, this information will no longer available with this change. → Maybe we need an additional event?

**Original Pull Request:** https://github.com/doctrine/orm/pull/10874 **State:** closed **Merged:** No --- This PR moves the `postFlush` event dispatching _after_ final clean-up steps in `UnitOfWork::commit()`. The idea is that at this time, `commit()` is "as done as it gets", and it might be possible to call `EntityManager::flush()` again from event listeners – we'd return from that method on the very next line, and everything would be in the same state if users dediced to call `flush()` again themselves. Obviously, infinite recursion is one thing either the ORM or users would need to think about. The intent is to make it somehow possible for users to have event listeners that get notified e. g. through `postPersist` to prepare "cascading" changes. These changes could be collected and applied in a `postFlush` listener, which might then call `flush()` again. This sparked off from #10869, where the reporting user is calling `flush()` even from `postPersist` – a questionable practice, probably never endorsed but it "somehow worked" until 2.16.0. ⚠️ BC Break: If `postFlush` listeners inspect UoW state through methods like `isSchedulesForInsert` or `getEntityChangeSet`, this information will no longer available with this change. → Maybe we need an additional event?

admin added the pull-request label 2026-01-22 16:14:48 +01:00

admin closed this issue

2026-01-22 16:14:49 +01:00

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#12671

[PR #10874] Emit postFlush events as the very last thing in UoW::flush() #12671

[PR #10874] Emit `postFlush` events as the very last thing in `UoW::flush()` #12671