Hangfire Automatic retries - how to manually configure the time between retries
Asked Answered
E

3

19

I have a requirement to manually configure the time between retries. I was not able to find the way for it.

But I found a code from https://github.com/HangfireIO/Hangfire/blob/master/src/Hangfire.Core/AutomaticRetryAttribute.cs

which schedule job after maximum number of retries are finished.

public static readonly int DefaultRetryAttempts = 10;

I have changed above property DefaultRetryAttemts to 3 instead of 10 then also it is taking 10 retries for a single job

'Retry attempt 7 of 10: Error while importing data'

My requirement is to have 5 retry attempts and provide 20 minutes delay after each retry.

Expiation answered 24/11, 2017 at 13:36 Comment(0)
B
22

This feature has been merged to version 1.7 beta. For whoever wants to get the feature early, copy the new AutomaticRetryAttribute code to your project, rename it to AutomaticRetryExtAttribute and apply both attributes to your job.

[AutomaticRetry(Attempts = 0)] is applied to prevent it from rescheduling jobs upon failure. It is important because we want AutomaticRetryExt to handle the rescheduling instead.

[AutomaticRetry(Attempts = 0)]
[AutomaticRetryExt(Attempts = 30, DelaysInSeconds=new int[] { 300 })]
public static async Task Download(string fileName)
{
}
Blackheart answered 14/11, 2018 at 5:51 Comment(0)
H
11

If you want to make it global, you can do it so by adding a global filter on your startup configuration:

GlobalJobFilters.Filters.Add(new AutomaticRetryAttribute { Attempts = 5, DelaysInSeconds = new int[] { 300 } });

You can even specify each retry timeout by having:

DelaysInSeconds = new int[] { 300, 400, 500, 600, 700 }
Houseman answered 3/5, 2021 at 10:8 Comment(0)
N
1

This feature has been merged in Hangfire trunk and should be available in version 1.7. See the pull request

You may just look at the pull request and retrieve the code of the AutomaticRetryAttribute to build your own custom attribute.

Nonchalant answered 24/11, 2017 at 20:41 Comment(1)
I would recommend against this practice - it creates extra code you have to maintain/test and then when the feature is released you still have to refactor all your code to match the new method interfaces.Fiske

© 2022 - 2024 — McMap. All rights reserved.