Initial delay

[psh05]

@tomazfernandes Is it possible to set an initial delay of x hours then set a different delay for subsequent retries?

[tomazfernandes]

Currently I don't think we can, but I think we could add a delayed property to the builder and annotation and add that to the first back off.

If @garyrussell is ok with this, I think you can open an issue for this enhancement.

Thanks for the suggestions!

[psh05]

Just to clarify when I said "then set a different delay for subsequent retries" - I meant e.g. 24 hours for the first delay followed by a retry of 5m, 1 hr, 2 hr.
Will wait for @garyrussell to confirm then happy to create an issue!
Thanks!

[tomazfernandes]

Ok, so for example @RetryableTopic(initialDelay="1d", @BackOff(delay="5m", multiplier="2.0")), would result in the first delay of 24h, then 5m, 10m, 20m, and so on for the number of attempts. Is that correct?

Of course, the first delayed attempt also counts as an attempt, so if it's 5 attempts, would be 0, 24h, 5m, 10m, 20m.

[garyrussell]

Sorry - too many balls in the air - I think providing the hook for a custom back off should be enough at this time.

[tomazfernandes]

No worries, sounds good, thanks @garyrussell

[psh05]

Yeah @tomazfernandes the custom delay worked, thanks for that! (Currently testing it with a longer delay so will let you know if I have any issues)

1. I think it would be good to have the initial delay with a backoff (as the example you gave - don’t think you can currently do that with a custom backoff) and an initial delay with a fixed delay (e.g. 24 hr, followed by 5x 1 hr. This could be done with the custom delay however you have to define the 1 hour delay 5 times and this is just an example). Are you happy to proceed with an issue for this?

2. I tried to retrieve the delivery attempt using the DELIVERY_ATTEMPT header but that didn’t seem to work (no messages were consumed and no errors). Any ideas or if there is a different way to get the retry/delivery number?

[psh05]

@tomazfernandes @garyrussell Sorry to chase! Any thoughts on my last comment?

[tomazfernandes]

Hi @psh05, sorry, some other issues came along and I didn't reply.

I'm not sure about having this initialDelay setting in the annotation considering the same result can be achieved with a custom backoff policy - I think it's usually better not to pollute the annotation unless really necessary.

If you need to automate the delay values creation, you can use the BackOffValuesGenerator class - you provide the BackOffPolicy and number of attempts, and it'll return a list of delays. Then you can add your initial delay and pass on to the custom back off.

But I'd like to hear @garyrussell's thoughts.

For the attempts count, the attempts information is in the RetryTopicHeaders.DEFAULT_HEADER_ATTEMPTS header (retry_topic-attempts).

Let me know if that works for you.

Thanks

[Ramenbet-giris]

Yes, it's possible to set an initial delay of x hours and then use a different delay for subsequent retries. Most job processing frameworks support this through custom delay logic or retry configurations.

[Ramenbet-giris]

For example, you can configure the first delay manually (e.g., 2 hours) and apply a retry strategy for later attempts (e.g., exponential backoff or fixed intervals). This is often done with hooks or middleware in frameworks like Sidekiq, BullMQ, or Celery.

[Ramenbet-giris]

If your framework doesn’t natively support this, you can programmatically check the attempt count and adjust the delay accordingly. Let me know your specific use case or framework for further details!

[PlayF0rtuna]

Yes, you can set an initial delay of x hours and a different delay for subsequent retries in most job processing frameworks by combining manual configuration and retry strategies.

[PlayF0rtuna]

For the initial delay, configure it explicitly (e.g., using a countdown or delay setting). For retries, use a backoff strategy or custom retry logic to adjust the delay dynamically.

[PlayF0rtuna]

If the framework lacks native support, you can write custom logic to check retry counts and apply specific delays for the first and subsequent attempts. Let me know your setup for more details!