cylc trigger --flow=n option

[hjoliver]

If you trigger a task (with or without reflow) ahead of the main flow(s) it should generally behave as described in #4651 (comment) - i.e. following flows should not be affected unless they catch up and merge in the scheduler task pool (if they do catch up, merging is necessary until #4419).

I haven't thought of a use case, but we might want the ability to set the flow number of the triggered tasks so that a following flow with the same flow number stops when it reaches that point in the graph? (Note: not when it "catches up" in the task pool, but when it reaches points in the graph were covered in the new flow - i.e. when the spawn-time DB check says "this task was already spawned earlier in this flow").

[oliver-sanders]

Some possible use cases badly outlined here.

Turning this around do we have a use case for running a task ahead of the scheduler where we would not want the task to be considered a part of any flow at all? If so how do we represent this in the UI?

See also #4657 which is a reformulation of the same matter.

[hjoliver]

As noted on the other issue, I agree we need the ability to trigger a future task that belongs to the current flow, as well as to another flow, or to no flow. I hadn't thought of a use case, but I hadn't ruled it out (somewhere we have - SoD proposal or issue predating this one - a comment to the effect of adding the --flow= option to cylc trigger to bring it in line with cylc set-outputs in that respect).

Turning this around do we have a use case for running a task ahead of the scheduler where we would not want the task to be considered a part of any flow at all?

Experimenting with task modifications the lazy way: by triggering "out of the way" tasks in your running workflow instead of deploying another instance of the whole workflow and figuring out the setup to run a single task from it (the sort of thing that used to be possible with cylc submit).

Also: triggering a single past task to regenerate some legit products of that task, without flowing on to child tasks even though they exist. The triggered task can't have the original flow number ("error: task already spawned in this flow"), so it has to have a different flow number, or no flow number. Currently having a flow number will cause an ongoing flow, which we don't want (in this example).

If so how do we represent this in the UI?

I don't know, some badge that says this is a one-off task that will not flow on in the graph? We haven't even decided how to effectively represent multiple flows yet.

[hjoliver]

Superseded by #4686