optional outputs: tasks which complete outputs on multiple tries marked as incomplete

[oliver-sanders]

A nasty bug where a task which generates multiple required outputs, but over multiple submissions, is erroneously marked as incomplete.

[scheduling]
    [[graph]]
        R1 = """
            a:1 & a:2 & a:3 => z
            a?
        """

[runtime]
    [[a]]
        script = """
            cylc message -- $CYLC_TASK_TRY_NUMBER
            false
        """
        execution retry delays = 2*PT0S
        [[[outputs]]]
            1 = 1
            2 = 2
            3 = 3
    [[z]]

Selected log entries:

INFO - [1/a running job:01 flows:1] (received)1 at 2023-12-15T15:20:24Z
WARNING - [1/a waiting job:01 flows:1] retrying in P0Y (after 2023-12-15T15:20:29Z)
INFO - [1/a running job:02 flows:1] (received)2 at 2023-12-15T15:20:34Z
WARNING - [1/a waiting job:02 flows:1] retrying in P0Y (after 2023-12-15T15:20:37Z)
INFO - [1/a running job:03 flows:1] (received)3 at 2023-12-15T15:20:42Z
INFO - [1/z waiting(queued) job:00 flows:1] => waiting
INFO - [1/z waiting job:01 flows:1] => preparing
INFO - [1/a running job:03 flows:1] => failed
WARNING - [1/a failed job:03 flows:1] did not complete required outputs: ['1', '2']
INFO - [1/z running job:01 flows:1] => succeeded

So all three custom outputs are received, and the downstream task does run, but the upstream task remains (erroneously) marked as incomplete.

[oliver-sanders]

The good news is that this example works correctly with #5658, however, it produced some confusing warnings in the process:

INFO - [1/a/01:running] (received)1 at 2023-12-15T15:28:09Z
WARNING - 1/z does not depend on 1/a:1
WARNING - 1/z does not depend on 1/a:1
...
INFO - [1/a/02:submitted] (received)2 at 2023-12-15T15:28:16Z
WARNING - 1/z does not depend on 1/a:2
WARNING - 1/z does not depend on 1/a:2
...
INFO - [1/a/03:running] (received)3 at 2023-12-15T15:28:24Z
WARNING - 1/z does not depend on 1/a:3
WARNING - 1/z does not depend on 1/a:3

Eh? 1/z only depends on 1/a:1, 1/a:2 & 1/a:3?

And why are they in pairs, is there a duplicate method call?

[hjoliver]

Eh? 1/z only depends on 1/a:1, 1/a:2 & 1/a:3?

And why are they in pairs, is there a duplicate method call?

A double count, not a duplicate call. It resulted from a recent silly error (on the cylc-set branch) in the way I computed and logged which outputs were not valid for a particular preqrequisite satisfaction attempt.

Anyhow, fixed now.

I've changed the milestone to 8.3.0 since it was already fixed on 8.3.0 cylc-set PR branch (apart from the above logging error).

[MetRonnie]

Everything now working as expected for me on #5658, no unexpected warnings