https://bugs.kde.org/show_bug.cgi?id=397776
TallFurryMan <eric.dejouha...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eric.dejouha...@gmail.com
--- Comment #1 from TallFurryMan <eric.dejouha...@gmail.com> ---
I agree partially. The original use case for START_AT is that the job must
start at the given date, not that the job can start from the given date.
Therefore when the start date is in the past, the job is made invalid.
I didn't change the implementation of this use case when refactoring the
scheduler, because it is valid in the case the observation has to be made at a
certain time and not another. My opinion is that you found that "to be made at
a certain time" is incorrectly implemented.
Let's consider the case of a START_AT job with no repeat.
At the very least and generally, I think that if the job was running before a
transitory error it should be continued when the error disappears. The
Scheduler should not reconsider all the jobs and potentially choose another
one. But I would expect this to work currently, as I don't think the Scheduler
is changing currentJob until it switches to another job.
Now the real bug might be that if the START_AT job is aborted, re-evaluated,
and is still in a relevant timeframe compared to its estimated time (say the
job takes 4 hours and is re-evaluated after 1 hour), the Scheduler should not
consider that this job is invalid.
If we add the repeat configuration into the equation, it affects the estimated
time, so the previous paragraph is still valid. The only edge case is
LOOP_INFINITE, where there is no estimated time.
I agree with your suggestion to implement a new behavior for START_AT jobs for
multiple reasons, but I would prefer we solve all the issues with the current
design first.
--
You are receiving this mail because:
You are watching all bug changes.
