So in order to avoid workflows from stalling due to a short runahead limit, I set mine to four days’ worth to keep things alive on non-24/7 monitored systems so after a weekend I can come back to things still running even if something fails Friday afternoon.
What this leaves me with is a very long list of tasks in the workflow tree view in the GUI. How do I control the sort so the oldest cycle point is at the top?
I know a similar question was asked mid last year but my ask is just about cycle points which aren’t as dynamic as tasks are.
There should be a tick box in the settings page (Dashboard > Settings) for “Latest Cycle Point at Top”. Unticking this should put thhe oldest one at the top.
If it’s a particular task that is expected to fail occasionally, you could avoid a long runahead limit by marking its success as optional (and possibly handling the failure with a fail trigger too). Then if it fails it won’t be retained by the scheduler as an incomplete task, and so it won’t cause a runahead stall.
(Just wondering if that would be appropriate, because if the workflow can continue despite the failure, the failed task presumably isn’t on the “critical path” in the graph).
In our case, it’s more of trying to prevent things from dying over the weekend. In our production environment tasks will be monitored so it will be less of an issue. I might comb through and make the appropriate tasks optional but extending the runahead limit has been an acceptable solution so far.
I’m still getting used to the dynamic loading of tasks vs Cylc 7’s preloading because I’m so used to looking at the graph to see if something has happened or not, where as now I can’t tell if something has happened and has been removed from the graph or if it hasn’t loaded yet, unless I memorize all the dependencies of all our workflows… Also missing “cylc show” in the GUI … unless that’s another obvious button I’m overlooking.
That change was a necessary efficiency enhancement, to support increasingly large and complicated workflows, particularly for the web UI.
However, the “n=1 window” around active tasks is only the default. You can widen it with the “set window extent” option in the workflow drop-down menu. Then you’ll see more succeeded tasks out the back, and more waiting tasks up front.
An option to see all the tasks in all active cycle points is also planned for a future release, for use in relatively small workflows.
Not yet (and that might be dangerous, if you start a really big workflow). But we do plan to make the window extent more easily configurable. Currently the default is always n=1 and the setting is a bit hidden.
… unless that’s another obvious button I’m overlooking.