https://bugs.kde.org/show_bug.cgi?id=398415
Bug ID: 398415
Summary: Repeated Scheduler jobs are aborted before they
actually repeat
Product: kstars
Version: git
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: mutla...@ikarustech.com
Reporter: eric.dejouha...@gmail.com
Target Milestone: ---
When a repeated Scheduler job finishes a batch, it shifts to aborted state
before effectively repeating.
Steps to reproduce:
- Create a Scheduler job that has repeats, and starts now,
- Run the Scheduler,
- Observe as job finishes a batch, aborts indicating its startup time is in the
past, then restart for the next batch.
This situation is triggered by the startup time which is calculated at the
first batch, and is re-considered when checking for the new batch. START_ASAP
jobs get configured as START_AT when they are evaluated. When a batch finishes,
jobs go through state COMPLETE so that they re-evaluate before being repeated,
and the re-evaluation doesn't consider the original startup configuration.
The same situation occurs with real START_AT jobs, but those by design need to
really start at the time they are planned, not at another time.
Thus in order to avoid regressions, this issue should probably not be fixed by
considering START_AT/START_ASAP original startup configurations, but by
checking if a repeat is remaining when finding a job that was configured to
start too far in the past.
--
You are receiving this mail because:
You are watching all bug changes.
