cylc
remove: update data store after task removal
If multiple flows are present in the graph and a task is cylc remove'd, it is possible that the flow numbers on projected future tasks (aka ghost tasks) may require recomputation.
E.g:
- Trigger a task in flow 2 whilst the workflow is paused.
- The downstream tasks should appear in the datastore in flow 2.
- Remove the task that you triggered.
- The downstream tasks will stay in flow 2.
- Reload the workflow.
- The downstream tasks will go back to flow 1 because the datastore has been rebuilt.
There was some suggestion on https://github.com/cylc/cylc-ui/pull/2016 about not showing flow numbers for future tasks which might provide an alternative workaround.
There was some suggestion on https://github.com/cylc/cylc-ui/pull/2016 about not showing flow numbers for future tasks which might provide an alternative workaround
Presumably that is much easier, and (IMO) it is sensible. Flow numbers are assigned to future tasks when they are spawned in a flow (and IMO that is maps to the conceptual model, not merely implementation).
The n-window is expanded around active flow(s) so this projection of flows into the future is perfectly valid and could be useful information (e.g. to answer the question why is this task in the workflow). The only thing that can meddle with this is flow-merging which is runtime bound so cannot be predicted in advance. It might also be awkward to omit the flow field as the UI will need to be able to tell the difference between flow=none and flow=undefined for presentation purposes.
I haven't picked a side yet myself, but both have merits.
flow=none in the GraphQL JSON format is flowNums: '[]', compared to undefined if they would be omitted from the data store
The only thing that can meddle with this is flow-merging which is runtime bound so cannot be predicted in advance
And (these also can't be predicted in advance):
- manual triggering
- optional branching
It also helps to clearly delineate the future graph from the past: no flow numbers because no flows have traversed the graph here yet.
Linking in https://github.com/cylc/cylc-ui/issues/2179 which covers differentiating n>0 tasks in the GUI.
A suggestion there is to wipe flow numbers for n>0 tasks which would cause them to be displayed the same as removed tasks.
There would be no need for changes to cylc-ui or cylc tui as these both already respect no-flow tasks.