Workflow invocations state for successful invocations and embedded

[itisAliRH]

Describe the bug

1. All successful workflow invocations have scheduled state
   
2. Embedded workflow invocations state are unknown when parent workflow is scheduled, cancelled or failed.
   
3. Invocation state in the table shows the initial state when the list loaded not the last one
   

Galaxy Version and/or server at which you observed the bug
usegalaxy.org (v23.0.rc1)

To Reproduce
Steps to reproduce the behavior:

1. Go to Workflow Invocations from the User menu
2. See successful/cancelled/failed invocations state

Expected behavior
Show successful for successful invocations and show the state of embedded workflow invocations based on their parent state and show the last state of each in the table

[mvdbeek]

1. All successful workflow invocations have scheduled state

I don't think that's a bug, they are scheduled. That has nothing to do with job states, so that is the only thing that really makes sense there. You can easily have failed jobs in a "successful" invocation. Are you maybe looking for an additional count of how many jobs are ok/paused/errored etc ?

2. Embedded workflow invocations state are unknown when parent workflow is scheduled, cancelled or failed.

Can you elaborate what you've done to reach that state ?

3. Invocation state in the table shows the initial state when the list loaded not the last one

Yes, there is no polling for updates. Possibly the reason for 2 ?

[itisAliRH]

1. All successful workflow invocations have scheduled state

I don't think that's a bug, they are scheduled. That has nothing to do with job states, so that is the only thing that really makes sense there. You can easily have failed jobs in a "successful" invocation. Are you maybe looking for an additional count of how many jobs are ok/paused/errored etc ?

I thought The "scheduled" state refers to an invocation that has not yet run and is waiting to run, and it would be appropriate to have another final state, such as "completed" or "finished," to indicate that the invocation has been completed regardless of the result.

2. Embedded workflow invocations state are unknown when parent workflow is scheduled, cancelled or failed.

Can you elaborate what you've done to reach that state ?

One of the failed invocations failed for an unknown reason and the other one failed due to it having wrong dependencies (each image shows a workflow and the workflow embedded in it):


I have cancelled an invocation just after running it by clicking on the x button

3. Invocation state in the table shows the initial state when the list loaded not the last one

Yes, there is no polling for updates. Possibly the reason for 2 ?

I think yes

[mvdbeek]

Scheduled means the invocation has been scheduled successfully, that means all steps have been created in the database. If jobs for all steps can be scheduled ahead of time it's often fairly quick / immediate, but it can happen that we can't create jobs yet because no reference to intermediate datasets exist, in that case the scheduler is waiting until that is the case.

You've seen the other cases, an invocation can be cancelled (on user request or be deleting the history) and it can fail (for a variety of reasons, like output datasets that are never going to be produced, or if jobs fail that are required in order to proceed scheduling more jobs).

[mvdbeek]

We should probably explain ^^ in a glossary or tooltip or something like that

[mvdbeek]

That actually happened
and there's #17708 to make the two states easier to see.