Command task matching requirements

[hjoliver]

Supersedes: #5763, #5695

See also: #5752, #5416, #5677

TODO:

• hold
• set
• trigger
• release
• kill
• poll
• remove
• show
  • show command
  • Update the troubleshooting page to remove the note about cylc show not working outside the n=0 window.

target task population

Different commands need to select tasks from different populations:

command	population
hold, set, trigger	pool, future, past
release	held-tasks list only #5752
kill, poll	pool only
remove	pool, past
show	pool only (but maybe future, past too #5677)

task name wildcards

We need to support matching task names by glob (or regex) and family name in all cases (not just in the pool.

For future and past tasks this means:

• find all matching task def names (or member tasks of matching family names)
• check which are valid for the given cycle point(s)

cycle point wildcards

We need to support matching cycle points by glob in the pool, e.g. to target all incomplete tasks.

We should not support cycle point wildcards outside of the pool (well, * is certainly bad; [5-8] (e.g.) may be OK in principle but still dangerous and not that much of a plus to users anyway).

task qualifiers

Use of some task qualifiers (i.e. :output) necessarily restricts matching to the pool. E.g. cylc set --out=succeeded "*:failed" should set all n=0 incomplete failed tasks to succeeded.

We can probably decide that use of any qualifier means pool only (is there any need to distinguish between e.g. completed-succeeded and completed-failed past tasks?)

---

Terminology:

• pool: task proxies in the n=0 active window
• future, past: abstract tasks anywhere else in the graph, i.e. n>0 and n<0

[hjoliver]

Update to the above, regarding cycle point wildcards:

• it would not be OK to allow cylc trigger */* in an infinite workflow - that would cause a meltdown
• but it would be OK to allow cylc hold */* - that just means "hold any task that gets spawned" which is perfectly safe

So that's another difference in task-matching requirements for different commands.

[hjoliver]

task name wildcards

We need to support matching task names by glob (or regex) and family name in all cases (not just in the pool.
For future and past tasks this means:

• find all matching task def names (or member tasks of matching family names)
• check which are valid for the given cycle point(s)

Note we already have the machinery to determine if given tasks (by name) are valid at a particular cycle point.

There is still potentially an issue as to whether the task would actually end up running there automatically due to optional branching (or even manual interventions) upstream of it.

However, I don't think that really matters, because:

• if you manually set or trigger such a task, you are saying do it now regardless of that
• if you (say) hold such a task, that essentially says "hold it IF it gets spawned in the future". If it doesn't get spawned we're just left with a small housekeeping problem in the hold list.

Finally, for task names, this "problem" (if it is one) applies equally to individual future tasks - which we already allow. For a family name or glob, we just end up with more tasks at the target point.

[dwsutherland]

Agreed this is needed ..
And if it is to work using a broadcast style/approach, without reading context (which may address this), we should think about using a pop-up window in the UI to show all current broadcasts/actions.
This means we/users can just click an x on whatever items/future-actions we want to stop/undo (i.e. those that don't or haven't decay(ed) naturally with task completion).