Retraso en el reintento y estrategia de reintento

@weaverryan or anybody who knows; is there a specific reason why the MultiplierRetryStategy is marked @final? I want to reuse all of the logic, except for when a specific exception is thrown (in that case I want to change the waiting time). I can't decorate the service either, since it's marked abstract.

Hey @Sven!

Sorry for the slow reply :). Hmm. It looks like I did that https://github.com/symfony/symfony/blame/b4d215c96fee8e208cdc82945b657a62913f9320/src/Symfony/Component/Messenger/Retry/MultiplierRetryStrategy.php#L31 ;)

The reason is mostly that, in Symfony, we tend to make things final until someone has a legitimate case for sub-classing them. And the answer is usually that you should use decoration. But I see your point about the service being abstract: https://github.com/symfony/symfony/blob/b4d215c96fee8e208cdc82945b657a62913f9320/src/Symfony/Bundle/FrameworkBundle/Resources/config/messenger.php#L157

However, you should be able to decorate the concrete version of this: a concrete service is made for each transport: https://github.com/symfony/symfony/blob/b4d215c96fee8e208cdc82945b657a62913f9320/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php#L2275 - so decorate THAT service id, and I think it should work.

Let me know if that works :). It looks doable to me - though needing to hunt down these specific, concrete service ids is a bit tricky.

Cheers!

You mentioned in the video a way to override the way of retrying messages and implementing one on our own.
Apparently, it's terribly what I needed right now on my project and the scarce info regarding the subject, even after checking the documention, isn't really making it easy to implement.
Do you have any study material regarding it?

Hey @Vandarkholme

I haven't implemented a custom Retry strategy but I think you can do it without much troubles.
First, you have to create a class that implements Symfony\Component\Messenger\Retry\RetryStrategyInterface
Then, put your new services id in messenger config

// config/packages/messenger.yaml
framework:
    messenger:
        transports:
        name:
            retry_strategy:
                service: App\Your\ServiceStrategy

And last, you have to implement the methods defined by such interface. You can give a look to this class to get an idea of what to do Symfony\Component\Messenger\Retry\MultiplierRetryStrategy

I hope this helps. Cheers!

Hey!

I think i found a bug in the messenger:
- i sent my messages as persistent (delivery_method=2) to RabbitMQ
- those messages in the actual queue were persistent (correct)
- when the worker consumes a message but it fails, the retry mechanism is called and a temporary queue is created where the message was sent
- this is correct, BUT and here comes the bug
- the message in that temp queue is not persistent, so if my retry mechanism has a delay of days... and the server/service stops/restarts those messages will be lost
Did i do something wrong or the bug really exists?

Thank you for your great work on symfonycasts!

Hey @Richard!

Ah, it is very possible this is a bug! But... it there *may* be a finished PR that will fix this - https://github.com/symfony/...

If you're interested, you could hack that onto your system and see if you get a better result - I would actually love to know if that fixes things for you. If it doesn't fix it, I would need to look closer, but indeed - my guess is that this would be a bug.

Cheers!

Thank Symfony Cast for the great video!

After we send a message with a DelayStamp to tell to execute the message in next 5 days
If later we want to extend the delay into 10 days, is it possible ?

Thanks,
Alex

Hey Nfq A.!

Hmm, so you want to send the message with a 5 day delay. Then, *before* it's processed, you want the ability to *extend* that delay to 10 days? I don't think that's easily possible. Basically, the nature of queues are that once you put them into a queue... you are just supposed to "dumbly" read them out when they become available. There would be no way to "ask" the queue for a specific message so that you could change the stamp.

However, this *is* possible... you just need to handle it in your app :). For example, you could set some database flag that says the message isn't ready to be processed yet (or even a date when it *should* be processed). Then, when the message is consumed after 5 days, your handler would check for this. If the message *is* ready to be processed, it would handle it. If not, it would take that message and re-send it into the message bus with a new, 5 day delay (the original 5 day delay + the new 5 day delay = 10 days).

I hope that helps!

Cheers!

Thank you Weaverryan,

That solution is very simple and totally fix my need!

(by the way I am very happy when received your answer the first time, I has followed your tutors for a long time, which helped improving my skills and mindset a lot! ^^ )

Happy day and keep the good work SymfonyCasts team!

Cheers!

Hey Nfq A.!

> That solution is very simple and totally fix my need

Yay, perfect!

> Happy day and keep the good work SymfonyCasts team!

Thanks to you for following us ❤️

Cheers!