Ok, got the example. Let's start saying that your requirements can be fullfilled (simply) decorating your function in a loop and break after the first successful attempt (and repeats=0, retry_failed=-1). Given that, the current behaviour is not properly a limit to what you are trying to achieve, it's only a matter on how implement the requeue facilities on the scheduler.
Lets keep the discussion open...if I got it correctly you're basically asking to ignore period for failed tasks (requeue them and execute ASAP) and reset counters accordingly... right ? Period right now ensures that no more than one task gets executed in n period seconds (and protects you from "flapping", i.e. a continously failing function, and is somewhat required e.g. for respecting webservices API limits, avoid "db pressure" if you're doing heavy operations, etc, etc). Respecting period in every case is "consistency" for me (because I decided that I can "afford" (or "consume" resources) executing that function only one time every hour). You are suggesting to alter this for repeating tasks....what I didn't get is that is required always or only when repeats=0 (that is, incidentally, not consistent :P) ?! i.e. What behaviour should you expect from (repeats=2, retry_failed=3, period=3600) ? 2.00 am, failed 2.00 am, failed 2.00 am, completed 3.00 am, failed 3.00 am, failed 3.00 am, failed ? This is basically what I'm missing. What could possibly be wrong at 2.00am and be right a few seconds later ? On Saturday, August 18, 2012 10:32:14 PM UTC+2, Yarin wrote: > > I think retry_failed and repeats are two distinct concepts and shouldn't > be mixed. > > For example, a task set to (repeats=0, retry_failed=0, period=3600) > should be able to fail at 2:00pm, but will try again at 3:00pm regardless > of what happened at 2:00. Likewise, if it was set to (repeats=0, > retry_failed=2,period=3600), and failed all three times at 2:00pm, the > retry count should be reset on the next go around. > > I think it's safer to presume that if a task is set up for indefinite > repitition, a failure on one repeat should not bring down the whole task- > rather the transactional unit that constitutes a failure should be limited > to the any given attempt, repeated or not. > > This was one of the reasons i pressed for renaming repeats_failed to > retry_failed- distinct concepts > > --
