Agreed on documenting use of a stop point rather than final cycle point, to allow extending a workflow run more easily.

But, a stop point requires trickier graph config if any graph structure is tied to the stop point, and users may not know in advance that they will want to extend their run. So I guess we'll still have to document how to do it the hard way as well, i.e., extending the final point.

As revealed by the discussion on #5952, it will be crucial to document that changing a final cycle point, or a stop point if the graph is tied to it, can implicitly change the structure of the graph, with potential consequences for the restart.

The simple example in that issue can be handled automatically I think, but I'm not sure that's universal.

So I guess we'll still have to document how to do it the hard way as well

We'd rather not, the FCP approach is conceptually awkward and are keen to move users away from it.

We've got a lot of users who rely on this pattern which was very simple at Cylc 7 but is very difficult at Cylc 8, we need to provide a simple solution for this use case.

We'd rather not, the FCP approach is conceptually awkward and are keen to move users away from it.

That's all very well, but it's going to happen anyway, as in "Help, my workflow finished, how do I move the FCP and continue it",

this pattern which was very simple at Cylc 7 but is very difficult at Cylc 8,

Hmm, moving the FCP was always a bit ill-defined and dangerous, even if it did work most of the time.

It's not so difficult now: restart with --pause and trigger the first cycle after the original FCP.

It's not so difficult now: restart with --pause and trigger the first cycle after the original FCP.

It really is, I find it hard! The triggering is often non-trivial and requires inspection of the workflow configuration, we cannot presently provide generic advice to do this or a single command like we used to have.

We'd rather not, the FCP approach is conceptually awkward and are keen to move users away from it.

That's all very well, but it's going to happen anyway, as in "Help, my workflow finished, how do it move the FCP and continue it",

Case in point https://cylc.discourse.group/t/extending-and-restarting-a-a-workflow/911

True but unhelpful, we would like to avoid using this pattern for workflows which are intended to be extended. Stop after cycle point is a very clean solution which cuts out the discontinuity between runs completely.

Will come back to this one and the associated issues when I get the chance.

I don't think we're disagreeing on the fundamental point here.

I'm just saying in addition to that, we still need to document how to restart after extending the FCP if you do get yourself into that particular fix.

Recommending a better way isn't much help if users don't anticipate the need for extending a workflow, or they don't see the advice, before starting a run.