Hmm, after checking the web2py-developers list (https://groups.google.com/forum/#!topic/web2py-developers/JC_bzRE6qo8) you might have a point Alex. But even just combining successful and failed runs won't work if whatever was causing the failure gets fixed because after a successful run the times_failed becomes zero and now you're going to calculate incorrect next_run_time values (they'll likely end up in the past) and just end up with your task running extra again. So not quite so simple of a fix as initially
On Sunday, February 21, 2016 at 9:44:41 AM UTC-6, Brian M wrote: > > Well I was looking at it as the task was still run by the scheduler even > if it didn't complete successfully so the run count should go up > regardless. If you are not using the prevent drift option then the > scheduler bumps forward the next run time whether or not the task was > successful so my change makes it do the same with prevent drift enabled. > Sure you could add together times run and times failed and use that to > calculate the next run time but I am not sure if there is any real benefit > to doing it that way. It would require at least a few more lines of code to > be changed/added which, at least in my view, means higher chance of > introducing another bug. For example the piece of the scheduler that > decides when a task has completed its asked number of runs would need > updating as well. The only benefit that I can see is that if desired the > developer could use the times run field as more of a times successfully run > field. But as it stands they could simply subtract failures from total > number of runs and get that anyway. > > I guess overall it comes down to whether that number of times to run field > should be "run this many times regardless of success" versus "run > successfully this many times". Of course if the developer of doing things > right (says the guy who obviously wasn't since he got bit by this bug) then > in theory failures shouldn't happen anyway. As for the fix, we can let the > main web2py developers decide which way they think is right now that the > problem and cause have been clearly identified. > > Brian > > On Sunday, February 21, 2016 at 7:14:33 AM UTC-6, Alex wrote: >> >> thanks for investigating on this, Brian. This really explains the strange >> behavior. As a bugfix I'd suggest to consider the failed runs for >> calculating next_run_time and not just times_run when prevent_drift is >> True. I guess times_run should not be updated in case of failed task. >> >> Alex >> >> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
