While looking into the AutomaticRetryAttribute code I saw that the class is sealed, and started wondering if there is any particular reason for it? I was thinking about the ability to define custom delays for different types of jobs based on configuration, by overriding the static method SecondsToDelay:
// delayed_job uses the same basic formula
private static int SecondsToDelay(long retryCount)
//Custom implementation here
Have you considered making the method public and unsealing some parts of the class? Or have plans for something similar? This would really help to define custom strategies without having to re implement most of the attribute’s capabilities.
This feature would be very handy… specifically for callbacks or web hooks emitted from an application.
Has something like this been implemented?
We do retries manually by running a continuous job having our own logic against callback records, based on retries on a Fibonacci sequence.
ie post/process, if there is a failure we then send after a 1 minute, then send after 1 more minute, then 2, 3, 5 etc up to x number of retries. This adds some resilience to our callbacks.
Having the ability to do this within HangFile would be really great, it would simplify callback code and storage of the various flags/dates etc.
[Just realised this post is 2 years old…]
Is there any feature about it? This is exactly what we need in business
The latest AutomaticRetryAttribute allows you to specify a list of delays.
I needed to have something a little more reactive in my jobs. So my job schedules itself on a delay that it calculated itself. Yes, the job has to know it’s being called from hangfire and needs that dependency injected, but it works perfectly.