cylc
xtriggers: tree view and beyond
Add Xtriggers to other views?
Issue #131 covers Xtriggers in the Graph View.
If the Queue and Retry states are removed and transformed into Xtriggers then these states will become invisible in the Tree view (and others).
Pull requests welcome!
I vote option 2, because:
A waiting task that is not "pending" or "submitted" must be waiting on something, so (a) no need to explicitly signify this at the top level, but (b) you should be able to expand the line to see exactly what it is waiting on:
- clock trigger (normal, or retry)
- internal queue
- xtrigger
- task prerequisites - we can show these here too, in the tree view!
BTW I vote option 2 as well, it's much neater and consistent with the idea that Xtriggers are "just another dependency".
Playing devil's advocate: we put the job icon in the task node to convey the important information without having to unfold, seems somewhat unbalanced to not do the same for the Xtrigger.
Playing devil's advocate: we put the job icon in the task node to convey the important information without having to unfold, seems somewhat unbalanced to not do the same for the Xtrigger.
Jobs are special, being "real" entities, not just workflow abstractions.
For waiting tasks, the "waiting" task icon is the important top-level information. We just need to expand the line (or do something to reveal extra information) to find out the detail of why it is waiting.
In other words, to my mind, jobs are super-important, whereas xtriggers etc. and just the detail of why a task is still waiting.
In other words, to my mind, jobs are super-important, whereas xtriggers etc. and just the detail of why a task is still waiting.
I was going to ask if users wouldn't want to see information on xtriggers, as tasks are collapsed by default. But the paragraph above answers my question.
Between option 1 and 2, I prefer option 2. For me the xtrigger in option 2 looks like a job, or another entity with similar idea.
But I thought it would actually qualify the task/job instead? It looks strange to me, but it's only because I got used to the existing icons.
task prerequisites - we can show these here too, in the tree view!
Probably a single line for task prerequisites (task dependencies) which you click on to see the n=1 graph around the task (not necessarily in the graph view)... or pop-up a list of text prerequisites as now.
@kinow - we're open to other ideas too, if you can think of a better way (@oliver-sanders said above, "option 1 or 2 ... or something else?"
The issue is, users need to be able to find out what a task is still waiting on, which can be any of the things listed above (clock triggers, xtriggers, etc.)
Option 1 is not good if we need to be able to show multiple dependencies, not just retries as in the diagram above.
But I thought it would actually qualify the task/job instead?
You can think of all these as qualifiers on the task waiting state, but we still have to figure out how to display them cleanly.
we're open to other ideas too
Always open to ideas BTW, whether it says "other ideas" or not!
Option 1 is not good if we need to be able to show multiple dependencies, not just retries as in the diagram above.
Another issue with option 1 is what to do when we have multiple Xtriggers. If a task has a wallclock trigger and belongs to multiple queues (which isn't actually that rare) it's going to be a mess.
Option 1 is not good if we need to be able to show multiple dependencies, not just retries as in the diagram above.
Another issue with option 1 is what to do when we have multiple Xtriggers. If a task has a wallclock trigger and belongs to multiple queues (which isn't actually that rare) it's going to be a mess.
Oh, I was going to write about badges on icons - I think someone suggested that before. But it wouldn't be possible to use this approach with multiple xtriggers.
Maybe we could have queue/xtrigger/etc icons to the right of the task name? Displaying some more info on the mouse over / touch tap?
Oh, I was going to write about badges on icons
That was one of my suggestions originally, I think. But it would be difficult with multiple "(x)triggers" - especially now I realised we should include task dependencies in this. There's no point in having a single badge to represent "one or more (x)triggers" because - as I said above - if a task is still waiting that in itself implies at least one unsatisfied trigger.
[cylc-con-2020]
Go for a mixture of options (1) and (2).
- Use a generic icon into the task row to show if the task is waiting on any xtrigger.
- List the xtriggers individually above the jobs.
- When xtriggers are satisfied change their icon to a tick or some other success icon.
- Queues are special, they appear next to the task icon and should disappear when satisfied.
Update 2022-04
- "Runahead" limit is now a task state modifier.
- "Queued" is now a task state modifier.
Proposal still holds, however, suggest:
- Removing items from the list when completed rather than marking them as done (more realistic as completed xtriggers don't exist in the task pool & data store).
- Using the task "modifier" (used for the held/runahead/queued indicator) to display the xtrigger. The indicator basically means "this task won't run yet because of one or more constraints" ... "expand the task to find out more".
Getting xtriggers into the tree view is a relatively high priority as they are currently completely invisible in the UI.
For the moment, users need to be aware that a waiting task in n=0, if not queued, runahead limited, or held (all of which are visible already), is waiting on an xtrigger. But yes, more than that would be nice!