This is a follow on discussion that I had with @weaverryan on Slack.

Messenger comes with some optional Doctrine related middle-wares. It seems to me, unless i'm missing something, that all of these do not make sense as middlewares, and would be better suited as EventListeners for consumption purposes.

I've reimplemented 3 of these for my project as EventListeners in my project, as they are unusable as middleware.

Let's have a look.

DoctrineClearEntityManagerMiddleware

Automatically Clears the EntityManager in an effort to prevent memory leaks.

I can't imagine a use-case where this would be beneficial when dispatching messages. Messages are most likely dispatched in a request context, in which case you really don't want your Entity Manager cleared as all your entities will become un managed, which will just result in errors or unintended consequences when the EntityManager is eventually flushed.

However, clearing the EntityManager is obviously beneficial when consume messages, to prevent memory leaks in a long running process.

It seems this middleware should be a Listener on consumption, listening on some combination WorkerMessageHandledEvent/WorkerMessageFailedEvent/WorkerMessageReceivedEvent

DoctrineTransactionMiddleware

Automatically calls EntityManager flush.

Again, exactly the same as above really.

1. As the developer, I want to be in control of calling when flush in a request context.
2. This middleware will not work at all and will throw an exception if you are dispatching messages during an existing flush i.e. subscribing to various doctrine events. (yes, you could debate here if this is a good idea or not).

It seems this middleware should be a EventListener, listening on WorkerMessageHandledEvent.

DoctrineCloseConnectionMiddleware

Closes the database connection.

More of the same really. This seems better suited to a long running background processes, i.e the consumer.

DoctrinePingConnectionMiddleware

Checks the database connection is alive, reconnecting and resetting the entity manger if not.

More of the same really. This seems better suited to a long running background processes, i.e the consumer.