feat: Drop exception catching and logging, fix retry and failure hand…

[mleczakm]

…ling by default messenger way

Fixes #205

[Rastusik]

heye @mleczakm ! thank you for the contribution!

I'm afraid I'm not able to merge this without a reproducer test.

But there is an important design question here - is it really needed to support retries in the task workers? The thing is that we're in non-persistent context here (php process memory). Retries usually use some kind of a durable queue. With too many retries in Swoole, I'm afraid there would be a risk for out of memory errors.

Maybe you should reconsider your design decisions?

[mleczakm]

@Rastusik That exception logging is also silencing errors. It breaks error handling in Symfony and interferes with message processing in Messenger. These are not my design decisions, but part of the Symfony Messenger design. Since this is a bridge for it, it should fully support that behavior.

What’s also important – it breaks the failed queue mechanism. While it can be fixed by reconfiguring services (so it's possible to fix it in userland), there’s no point in breaking the default framework behavior with no real profit - exception would be logged anyway.

[Rastusik]

I believe the exception catching is for a reason there (need to find time to look into it closer). if the exception won't be caught, the swoole worker process will terminate.
the point of this messenger integration is just to use the swoole task mechanism with a common symfony messenger interface.

I can look later where the deleted class is exactly hooked in, but I'm still not sure if I am the one who's missing context, or you, or us both :)