apscheduler
apscheduler copied to clipboard
Allow knowing which jobs are running (and not just submitted/pending and paused)
It seems like we can pretty easily know by looking at the job.next_run_time
whether a job is paused or not but it is really hard to know if a job is running or not (as far as a I can tell) since there is no apparent job state that is connected to a job saying the job is actively running (the event notification system is not reliable enough to do this, as it can be fired out of order).
So this is more of a feature request to have such a capability...
If more details are needed (or I can suggest some ideas on how to do it or maybe even a PR).
For some ideas, have each job have a job.state
attribute or method (currently they do not) and that state changes from one of [PENDING, SUBMITTED, RUNNING, PAUSED]
; then inside the scheduler during submit and run and pause that attribute gets modified.
I can not agreen with you any more, I want to show users the state of current job ...
This is doable but it requires a change to the executor API.
@wck821829906 maybe you can make a proposal for fixing this?
@agronholm , as I know that apscheduler has API 'get_job', this function return the job instance, if it is doable to let the job instance has the "status" attribute, or provide other api method to get the job status ?
Only the executor(s) know if a given job has been submitted or if they're currently running. This should not be stored in the Job object.
Also, if multiple instances of the same Job have been submitted to an executor and only one is running, what would you set as the state
then?
Oh, It is a problem, for multiple instance, maybe "running" state is resonable if has running instance ...
Either way, this logic needs to be something that queries the executor for the jobs' statuses and combines this with the next_run_time
attribute of Job.
Ya, maybe statii
then is better as an attribute of something.
The plural of "status" is also "status". Regardless, how would this new attribute work?
Oh, I thought it was 'statii' lol
+1
I'm trying to track state through event handlers, but so far keep running into problems with it (including #356). Whatever API changes are needed, I think they'll be worth it. This is a capability that any application with a robust UI will need to have.
This would be a nice feature to have