apscheduler icon indicating copy to clipboard operation
apscheduler copied to clipboard

Allow knowing which jobs are running (and not just submitted/pending and paused)

Open harlowja opened this issue 6 years ago • 14 comments

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).

harlowja avatar Aug 21 '18 17:08 harlowja

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.

harlowja avatar Aug 21 '18 19:08 harlowja

I can not agreen with you any more, I want to show users the state of current job ...

wck821829906 avatar Aug 27 '18 07:08 wck821829906

This is doable but it requires a change to the executor API.

agronholm avatar Aug 27 '18 08:08 agronholm

@wck821829906 maybe you can make a proposal for fixing this?

agronholm avatar Aug 27 '18 08:08 agronholm

@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 ?

wck821829906 avatar Aug 27 '18 09:08 wck821829906

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.

agronholm avatar Aug 27 '18 09:08 agronholm

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?

agronholm avatar Aug 27 '18 09:08 agronholm

Oh, It is a problem, for multiple instance, maybe "running" state is resonable if has running instance ...

wck821829906 avatar Aug 27 '18 09:08 wck821829906

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.

agronholm avatar Aug 27 '18 09:08 agronholm

Ya, maybe statii then is better as an attribute of something.

harlowja avatar Aug 27 '18 16:08 harlowja

The plural of "status" is also "status". Regardless, how would this new attribute work?

agronholm avatar Aug 27 '18 16:08 agronholm

Oh, I thought it was 'statii' lol

harlowja avatar Aug 27 '18 23:08 harlowja

+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.

ecbftw avatar Jan 28 '19 17:01 ecbftw

This would be a nice feature to have

Munanga avatar Jun 22 '22 15:06 Munanga