Polly retry based on Service Bus message retry count

Question

My current understanding is that Polly will retry the code to execute based on the policy defined.

What I would like to do is to have Polly work based on a ServiceBus message, so I'd provide the retry count to Polly and it would choose the appropriate behaviour based on policy - I could then repost the message with the appropriate properties (message id, retry count, the date/time the message becomes valid from).

For example, my retry policy would be to wait for 10 seconds (3 times), and then try every hour (12 times), and then deadletter.

I can't find anything that tells me if this is possible or not. Is this something Polly supports?

Answer 1

Yes you can do this, but you need to use two policies instead of just one.

The retry part

Policy
.Handle<SomeException>()
.Or<OtherException>()
.WaitAndRetry(new[]
  {
    TimeSpan.FromSeconds(10), //after the second attempt 10 seconds penalty
    TimeSpan.FromSeconds(10), //after the third attempt 10 seconds penalty
    TimeSpan.FromSeconds(10), //after the fourth attempt 10 seconds penalty
    TimeSpan.FromHours(1), //after the fifth attempt 10 seconds penalty
    ...
    TimeSpan.FromHours(1) //after the sixteenth attempt 10 seconds penalty
  });

Please bear in mind that retry will kick off after the first failed attempt. So 5 retries means at most 6 attempts.

The fallback part

Policy
 .Handle<WhateverException>()
 .Fallback(() => UseDeadletterQueue()); 

The ordering matters how do you combine these policies. The outer should be the fallback.

Put these pieces together

Policy.Wrap(fallback, retry);

or

fallback.Wrap(retry);

or

Answer 2

Poly controls user initiated code. When we talk about sending messages it would work, except you wouldn't be able to dead-letter a message that is failing a send operation. Only the broker can dead-letter messages.

Retries with Azure Service Bus for a message to be received wouldn't work with Poly as the originator of the retries (or any 3rd party for that matter). That's because receiving a message involves DelibeyCount set and tracked by the broker. If the value changes on the broker and is set to 5 but the code is configuring Poly to retry more than that, the message will be dead-lettered regardless.