GScan: don't show held/retry icons for stoppped workflows

[MetRonnie]

Held & retrying icons for stopped workflows is not useful.

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Tests are included
• Changelog entry included if this is a change that can affect users
• Docs not needed

[oliver-sanders]

If held and retrying are not considered useful for stopped workflows, then are the task states also not useful?

[MetRonnie]

A workflow may shut down (possibly after stalling) with failed tasks, which would be useful to see IMO

[oliver-sanders]

Trying to understand why we would want to display some task state information, but hide other information?

[MetRonnie]

Can we at least agree that it doesn't make sense to show held & retrying icons?

[hjoliver]

I think it matters if those tasks return to the same state (in some meaningful sense) after restart, right?

I think this happens at restart:

• tasks that are held do resurrect as held
• tasks that are waiting on a retry timer don't resurrect as waiting on a retry timer
  • but they resubmit immediately, so in a meaningful sense (?) they are waiting on retry while the workflow is stopped

So on that basis it seems to me we should show "held" and "retrying" for stopped workflows.

[oliver-sanders]

Can we at least agree that it doesn't make sense to show held & retrying icons?

Note really, this doesn't make a lot of sense to me, hence probing for motives.

Why would we clear one part of the task state (e.g, retrying) but not another (e.g, running)?

If there's a good reason to handle these differently, then fair enough.

[MetRonnie]

• Failed & submit-failed tasks: I think the case is clear here

  A workflow may shut down (possibly after stalling) with failed tasks, which would be useful to see IMO

• Running tasks: these are live at the time of shutdown so it makes sense to show, even if they will become out of date
• Submitted tasks: these will likely be still submitted or even running when the workflow is stopped, so it makes sense to show
• Held tasks: these are held and remain held - why would this info be useful while the workflow is stopped?
• Retrying tasks: these will not retry while the workflow is stopped, so why show them? Note any tasks that are waiting at shutdown could run immediately on restart, so I can't see the argument for special treatment of retrying tasks.

[oliver-sanders]

why would this info be useful while the workflow is stopped?

For the same reason it's useful to know a task has failed, it's something you will have to deal with when restarting the workflow.

I can't really see why some task state information might be considered helpful/relevant, but other information not.

Clearing some, but not all task state information seems a more confusing arrangement to me than just showing everything consistently.

[MetRonnie]

For the same reason it's useful to know a task has failed, it's something you will have to deal with when restarting the workflow.

I don't buy that the utility of any state info is for when you restart the workflow. You might have to deal with any number of waiting tasks when restarting the workflow, and that will become clear as soon as you do.

As I see it, the utility of state info is for after the workflow stopped - most importantly if it aborted