Laurynas Mališauskas

thanks for the response. i will see what our team can do to test this and possible make a PR. Will post updates here.

@torchello we changed our email infrastructure so this is no longer an issue for us. Feel free to make the PR yourself.

You can catch exceptions and delay/remove the message which causes it from resending it. an option not to make SQL transaction after EVERY message would be a truly better way....

@richsage sorry, but how this helps our problem? :) there is an obvious architecture issue when working with emails and DB. Handling failed emails is a different problem. When working...

@aistis- could you explain more? how we could control the flush moment when using DBAL? @richsage i will try to make one in some freeish weekend :)

@Ocramius could you give me some links to read about this? Never had a chance to read more about how the `UnitOfWork` works

what we have found so far that the fixture file was not changed between the point when it worked and now when it does not. what was changed is: *...

**UPDATE** User entity has a ```postPersist``` DoctrineEventListener. The listener creates and persists another entity ```LeadsPool``` which has no relations to ```User``` entity. The Notice starts appearing when we remove ```$entityManager->flush()```...

Anyone solved this issue? An example would be great. If provided i promise i will make a PR to documentation with it.