When a job is repeating, it is expected that its start time would be further in the past than the normal lead time, because it is repeating.
Therefore the evaluation of such a job when it repeats must not lead to an abort.
Details
Details
Use "repeated_scheduler_job_no_twilight_30s_leadtime.esl", Copy "3x30s_Red.esq" to "/tmp/kstars_tests".
Change the lead time to 0,5 minutes in the Ekos settings, so that a full batch is longer than the lead time.
There are 7 batches of the single target in the schedule. Run the Scheduler, observe as the first batch finishes.
Without the change, when a job repeat, a message is logged that that job is aborted, and that job is re-evaluated to restart.
With the change, when a job repeats, no message is logged, and that job repeats without state change.
Diff Detail
Diff Detail
- Repository
- R321 KStars
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Could you please be a little more specific with the test case? I cannot reproduce it yet.
Comment Actions
@wreissenberger Tell me what you think. Next fix on my list is a regression on scheduler jobs approaching dawn being restarted indefinitely, no easy test for now...
Comment Actions
I’ve seen the messages in my own logfile last night. I ca Test it late this afternoon.
Comment Actions
Ok, checked. I could reproduce it on master and with the patch the message disappeared.