At Cylc 7 we only had explicit task "subtraction" [1]. I.E, if you want to skip a chain of tasks or a sub-system within a workflow, you had to group them explicitly e.g. by using a family. These Cylc 7 use cases can all be handled by skip-mode which can match the same behaviour.

This issue suggests a new mechanism for implicit task "subtraction" where we determine the tasks to "subtract" by traversing downstream of the selected task(s) [2]. This avoids the need to pre-group tasks for intervention purposes. Presumably for your use cases, it is not possible to pre-empt the chains you want to "subtract" ruling out explicit "subtraction"?

In a strange way, this is actually a similar problem to "reflow" in that both are, in effect performing implicit task selection by traversing downstream from selected task(s). Reflow is implicitly determining the tasks to run, whereas implicit "subtraction" is determine the tasks not to run.

Implicit "subtraction" shares a similar difficulty with implicit reflow regards downstream consequences. E.G. if we explicitly "subtract" the task r, then we will implicitly subtract the chain x => y => z as intended:

a => r => x => y => z
a => housekeep

However, if we add this inter-cycle dependency:

x[-P1] => x

Or this intra-cycle dependency:

z => housekeep

Then the workflow will subsequently stall as a result of the "subtraction". Cylc doesn't presently have a graph-traversal utility to inform the user what is downstream of a selected task, and most real-world graphs are difficult to inspect graphically, so at present it is very hard for the user to tell whether a "subtraction" operation will cause a subsequent stall or not.

So how do we avoid the potential for an unintended future stall?

We have talked about termination mechanisms to restrict the scope of reflow, these could also apply here, however, these methods will rely on grouping which defeats the object of implicit task selection.

[1] Note: Using "subtract" in place of "remove" to avoid confusion with cylc remove. By "subtract" I mean subtracting a task from the graph.
[2] Note: The implementation might not actually traverse the graph, but this is, in effect exactly what it is doing.

This issue suggests a new mechanism for implicit task "subtraction" where we determine the tasks to "subtract" by traversing downstream of the selected task(s) [2]. This avoids the need to pre-group tasks for intervention purposes.

Yes, but I don't entirely agree with the characterization of this as "implicit", although I understand what you mean.

a => b => c => d & e  # with a currently running

If I explicitly expire c, and I'm not a complete idiot (which is arguable, to be fair) then I have explicitly told the scheduler not to run c and by obvious implication anything downstream of c.

That this should cause a stall is predicated on the following:

• the intervention may have been a mistake
• and (1) (if it was a mistake) silently omitting a bit of the graph is bad

But I'm countering this with the following:

• the intervention likely was not a mistake
• and (2) (if it was not a mistake) causing an unwanted future stall is bad

In fact (1) and (2) could be equally bad - they could both radically delay throughput at a time when I'm not around to fix the problem - by (1) restarting and triggering after a premature shutdown; or (2) removing the expired task causing the unwanted stall.

So I'm just saying our response to an intervention - especially when the consequences may occur later in time - should not be entirely based on assuming the user might have been wrong to do it in the first place.

Presumably for your use cases, it is not possible to pre-empt the chains you want to "subtract" ruling out explicit "subtraction"?

I presume by pre-empt you mean pre-emptively configuring a family that covers the whole sub-graph? Well I suppose it's always possible, but that isn't really good enough. The point is, I might not have done so, for whatever reason. Task families are primarily for inheritance of runtime settings, so it's perfectly reasonable not to think ahead and create additional families just in case they may be needed for particular interventions at run time. During development in particular, it's useful to be able to run or block completely arbitrary sub-graphs.

So how do we avoid the potential for an unintended future stall?

Unfortunately we can't know if the user "understands" what they are doing when they perform a potentially dangerous intervention. But despite that, such interventions are sometimes necessary.

So I think the best we can do is to warn the user and require explicit opt-in after the warning is issued.

(And by the way, even premature shutdown is not that hard to recover from in Cylc 8 - it's certainly not on the same scale as mistaken use of rm -rf for example).

Then the workflow will subsequently stall as a result of the "subtraction". Cylc doesn't presently have a graph-traversal utility to inform the user what is downstream of a selected task, and most real-world graphs are difficult to inspect graphically, so at present it is very hard for the user to tell whether a "subtraction" operation will cause a subsequent stall or not.

You raise a good point there ... posting a new issue: #6237

I'm closing this, not because it's invalid, but because the way I put the problem unfortunately created the impression of a competition between "branch cutting" vs "skipping" as ways to prevent a future sub-graph from running. The important thing is really that we need the ability to head off future stalls (due to future final-incomplete tasks) without having to wait unnecessarily for the inevitable stall to actually happen. With that ability, it enables branch cutting as a option where appropriate - but without circumventing our output completion safeguards. I'll put up a new issue for that.