workflow-state xtrigger: how to handle flows?

[hjoliver]

The workflow-state xtrigger polls until a task in another workflow achieves a status or generates an output.

#5809 adds flow-specificity (for the upstream workflow) but defaults to flow=1 as a possibly temporary measure.

Exactly what to do isn't clear to me:

• new flows result from manual interventions, which the downstream workflow doesn't know about
• choosing the latest flow number for the upstream task will only work if the task has been spawned already
• choosing the latest flow number in the upstream workflow won't work if that happens to be a self-limited flow that doesn't run over the target task

There may be no good answer to this. Downstream workflow operators will just need to be aware of the possibility that new flows may break their xtriggers, requiring the flow argument to be changed in the trigger call.

Perhaps we can detect the presence of multiple flows in the upstream workflow and raise an alert of some kind in the downstream one.

HOWEVER:

To mitigate this the cylc remove endgame (soon, but post-8.3.0 unfortunately) should make new flows unnecessary in most production use cases. Well, technically it is still a new flow, but cylc remove effectively erases the original flow (for target tasks) so that the new flow keeps the original flow number. So that won't affect cross-triggering.