Cylc UI gets confused if you set a task succeeded, failed, succeeded

[ColemanTom]

Description

Doing cylc set in order (at least of) succeeded, failed, succeeded gives incorrect symbol colouring. The status of outputs appears correct in cylc show, but incorrect (maybe?) in UI.

Reproducible Example

NOTE: Look at UI symbols in between each cylc set command, and on CLI to see the inconsistency.

1. Run any workflow
2. cylc set workflow//cycle/task (circle is fully coloured in)
3. cylc set -o failed workflow//cycle/task (circle now has a cross in it)
4. cylc set workflow//cycle/task (circle has no symbol or colouring)
5. cylc set workflow//cycle/task (circle still has no symbol or colouring)

Expected Behaviour

I think it should be showing as fully coloured in. However, I recognise that it is perhaps in a confused state.

[hjoliver]

Run any workflow

• cylc set workflow//cycle/task (circle is fully coloured in)

This completes the succeeded output of cycle/task - so the task icon goes to the succeeded state, just as if the task had run and succeeded.

If there are any tasks downstream of cycle/task that depend on its :succeeded output (and they have not already run in this flow) they will be spawned.

• cylc set -o failed workflow//cycle/task (circle now has a cross in it)

This completes the failed output of cycle/task - so the task icon goes to the failed state, just as if the task had submitted a second job (in the same flow) that failed.

If there are any tasks downstream of cycle/task that depend on its :failed output (and they have not already run in this flow) they will be spawned.

At this point cycle/task has completed two mutually exclusive outputs (succeeded and failed) - but that's OK because they were completed (in effect) by two different jobs.

• cylc set workflow//cycle/task (circle has no symbol or colouring)

This completes the succeeded output of cycle/task again. I think 🤔 this should change the task icon back to succeeded, just as if we triggered a 3rd job in the same flow and it succeeded.

(No downstream children will spawn because that would already have happened in this flow, the first time the output got completed.)

So ... restoring the bug label!

[hjoliver]

(Hang on, fail - I hallucinated some prerequisite setting there when in fact it was all output setting - reformulating and editing my response ... DONE)

[hjoliver]

(Issue probably needs to be moved to cylc/cylc-flow ... this is presumably a scheduler data store problem.)

[ColemanTom]

I wasn't entirely sure how to label this I admit. It feels like a very odd behaviour to do, but I did do it whilst monkey testing some things so I thought I should report it in case it is a bug.