Require completion of at least one optional output

[hjoliver]

Pasted from @oliver-sanders on Element chat:

E.G. here's the example I presented yesterday:

a:x? => x
a:y? => y
a:z? => z
x | y | z =? b

I said that Cylc would follow one of three possible pathways through the graph, but of course that's a bit of a lie. Cylc may follow zero pathways through the graph and shutdown as it is possible that a could succeed without generating any of the x, y or z outputs.

The awkward workaround is to force a stall with a pseudo dependency:

a => b

So our current interpretation of this:

a:x? => x
a:y? => y
a:z? => z

Is that "zero or more of x, y & z MUST be output"

However, it would be possible to interpret that as "one or more of x, y & z MUST be output" by making the assertion that when optionals (?) are used, at least one of them MUST be output. I think this is the user's intention for 99% of cases. The outliers being cases like this:

# we don't care if b fails
a => b?

Under this logic all pathways must be explicitly defined (explicit is better than implicit - PEP8), so we would have to explicitly state the error handling for the fail case here something like this:

a = b?
b:fail?  # if b fails do nothing

[hjoliver]

However, it would be possible to interpret that as "one or more of x, y & z MUST be output" by making the assertion that when optionals (?) are used, at least one of them MUST be output.

Agreed, but I think we need this to apply only to internal outputs.

(Note succeed and fail are already treated as special, because they are mutually exclusive).

Consider the case where success and failure are optional as well:

a:x? => x
a:y? => y
a:z? => z
a?
a:fail?
x | y | z => b 

The intention here would be that IF a succeeds, at least one of :x, :y, :z must be completed.

But a is allowed to fail too, in which case all bets are off on internal outputs.

If success is optional we can't just demand that one or more optional outputs must be completed, because then it would be OK for a to succeed without completing any of :x, :y, :z.

And if success/fail is (necessarily) treated as special, then I think its OK not to require explicit handling of :fail in this case:

# we don't care if b fails
a => b?

(Note that b? implies b:fail? because of the special properties of success and failure).

[oliver-sanders]

The intention here would be that IF a succeeds, at least one of :x, :y, :z must be completed.

Sadly I think mutual exclusion cases are simply not something we can handle with the global optional outputs logic as it stands. I think this may have come up in the proposal, I've gotta feeling that sub-graphs were touted as the answer e.g:

{
  a:x? => x
  a:y? => y
  a:z? => z
} => b

{
  a? => good
  a:fail? => bad
} => whatever

whatever & b => something_else

For now I wonder whether requiring at least one optional output to be generated would make it harder to make mistakes with graph branching.

[hjoliver]

The intention here would be that IF a succeeds, at least one of :x, :y, :z must be completed.

Sadly I think mutual exclusion cases are simply not something we can handle with the global optional ...

I agree, but note I was not talking about mutual exclusion cases there. ("at least one of", not "exactly one of".

My only point is just that we should not count :succeed? as one of the optional outputs that we require at least one of. Because if we do, the task can successfully finish without any of :x?, :y?, :z? being generated.

[oliver-sanders]

Superseded by #5640