Say you have an R1 task which sets up some information. At some point in the future, hundreds of cycles later, you need to rerun it to re-set the information up based on some change. How does one do this?
In Cylc 7, I could just do cylc submit --icp=current_cycle workflowname taskname.current_cycle. In Cylc 8, this does not exist. I have tried to do cylc trigger using various different options for the taskname (e.g. flow=all, flow=none, taskid */taskname, R1/taskname, <current_cycle>/taskname). I have not tried flow=new as I’m concerned that may have unexpected side effects. If I do cylc trigger using the actual real first cycle it does run, but, that means looking up what the first cycle ever was, which could be obtained from the top of the scheduler logs, but its extra steps I would prefer to avoid when doing this programatically.
What is the process to rerun an R1 task some time in the future, decoupled from its original cycle?
Cylc 7’s cylc submit command submitted a task as the scheduler would do it, but independently of the scheduler. We dropped that at Cylc 8 because it still affects the workflow run directory but leaves no record in the scheduler log or run DB, and that was generally agreed to be bad practice. In principle it could even conflict with jobs submitted by the scheduler at the same time.
Cylc 8 is more correct and careful. That’s mostly a very good thing, but it does mean that a few dodgy shortcuts like manually running a task at an invalid (for that task) cycle point will no longer work.
So yes, if you want to rerun a task that only appears in an initial R1/^ graph, you do need to know what the initial point (^) in order to get the task ID right.
Note however we have an upcoming change (already implemented, but yet to rise to priority for review) to provide completely separate startup and shutdown graphs that will make this sort of thing much easier.
No, but we should allow that - it is a pretty trivial code change.
BTW, for this purpose, now (with the correct initial cycle point) or possibly in an upcoming release with ^, you can use --flow=none or the default --flow=all to retrigger a past task without causing any downstream effects. (Flow none does not spawn any downstream activity; and all (all active flows) won’t either for a past task, because the active flows already passed by that point in the graph.