Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove: update data store after task removal #6540

Open
oliver-sanders opened this issue Jan 7, 2025 · 4 comments
Open

remove: update data store after task removal #6540

oliver-sanders opened this issue Jan 7, 2025 · 4 comments
Labels
could be better Not exactly a bug, but not ideal.
Milestone

Comments

@oliver-sanders
Copy link
Member

If multiple flows are present in the graph and a task is cylc removed, it is possible that the flow numbers on projeted future tasks (aka ghost tasks) may require recomputation.

E.g:

  1. Trigger a task in flow 2 whilst the workflow is paused.
  2. The downstream tasks should appear in the datastore in flow 2.
  3. Remove the task that you triggered.
  4. The downstream tasks will stay in flow 2.
  5. Reload the workflow.
  6. The downstream tasks will go back to flow 1 because the datastore has been rebuilt.

There was some suggestion on cylc/cylc-ui#2016 about not showing flow numbers for future tasks which might provide an alternative workaround.

@oliver-sanders oliver-sanders added the could be better Not exactly a bug, but not ideal. label Jan 7, 2025
@oliver-sanders oliver-sanders added this to the 8.4.1 milestone Jan 7, 2025
@hjoliver
Copy link
Member

hjoliver commented Jan 7, 2025

There was some suggestion on cylc/cylc-ui#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).

@oliver-sanders
Copy link
Member Author

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.

@MetRonnie
Copy link
Member

MetRonnie commented Jan 8, 2025

flow=none in the GraphQL JSON format is flowNums: '[]', compared to undefined if they would be omitted from the data store

@hjoliver
Copy link
Member

hjoliver commented Jan 8, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
could be better Not exactly a bug, but not ideal.
Projects
None yet
Development

No branches or pull requests

3 participants