Hello, I have rebased this PR, and addressed all comments. I should be OK now

I could rebase this PR, but before doing so, I prefer to be sure it's mergeable. so WDYT?

Edit: I have rebased the PR

So if the first message trigger and "error" level message, all others message will log and overflow the buffer.

From my experience, a worker running without processing messages can also go out of memory. For example if you have an app running in debug mode the tracing/profiling will keep event-dispatcher events in memory, eventually causing the process to go out of memory.

Because of this, should there also be a possibility to trigger the resetonWorkerRunning instead of just theWorkerMessageHandledEvent andWorkerMessageFailedEvent ?

And continuing on that, would it be nice if you could do a reset when the worker is inactive (Can be readWorkerRunningEvent->isWorkerIdle()) ? . So that if your reset functionality has a bit of performance impact, it could have less impact on the message handling performance.

From my experience, a worker running without processing messages can also go out of memory. For example if you have an app running in debug mode the tracing/profiling will keep event-dispatcher events in memory, eventually causing the process to go out of memory.

Indeed, cf#32422

Because of this, should there also be a possibility to trigger the resetonWorkerRunning instead of just theWorkerMessageHandledEvent andWorkerMessageFailedEvent ?

I don't understand :/

And continuing on that, would it be nice if you could do a reset when the worker is inactive (Can be readWorkerRunningEvent->isWorkerIdle()) ? . So that if your reset functionality has a bit of performance impact, it could have less impact on the message handling performance.

Indeed, that would be possible, in a next PR :)

If I understood the logic in this PR correctly, a reset is only triggered by on of thoseWorkerMessage.. events right? So it's only going to reset if messages are being consumed. What about a worker/consumer that's idle for a while? It could go out of memory for the same reasons and might benefit from reset of its services.

Ohhh, I see, good point. I need to check when the running event is triggered to ensure it does not break something

when the running event is triggered

I think it should be just as safe as the other events, it at least not during the handling of a message:

https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/Messenger/Worker.php#L95
https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/Messenger/Worker.php#L111

@Jeroeny Here we go 👍🏼 I pushed a new version where the listener listenWorkerRunningEvent too. Thanks for the hint 👍🏼

@fabpot I haved edited the PR description, and the configuration.
I'll open the doc PR asap (edit:symfony/symfony-docs#15796)

Thank you@lyrixx.