the original stop task branch will be truncated, and a new one "rebased" onto the new stop point

Sorry, I don't understand this.

I don't think the stop after cycle point config has any impact on the task pool does it? Restarting with a later stop CP doesn't appear to have any side effects?

I mean if the stop-task sub-graph has already started, but not finished, when the user stops or kills the workflow ... and then restarts it with a new stop-after-cycle-point.

Does this not have the same impact as changing the stop cycle (note cycle not task) at runtime (e.g. via cylc stop or cylc reload)?

It just pushes the stop cycle back (as requested) but continue as normal with no graph changes?

I mean if the stop-task sub-graph has already started, but not finished, when the user stops or kills the workflow ... and then restarts it with a new stop-after-cycle-point.

What I think Hilary may be getting at, is that in the example the stop cycle point is hardcoded and the stop cycle point task will remain 3000 unless the user changes it in the config and reloads: It might be worth warning users that this case requires a change to the jinja2 value and a Cylc VR. If you do cylc play --stop-cycle-point=3002 then the stop cycle point graph will change.

The CLI centric route around this would be -s 'STOP_POINT=3000'

Part of me thinks that it'd not be unreasonable to provide the stop Cycle point as a template variable.

(None of the test failures look related to this change)

What I think Hilary may be getting at, is that in the example the stop cycle point is hardcoded and the stop cycle point task will remain 3000 unless the user changes it in the config and reloads

The same applies to the initial/start/final cycle points?

Note, there is no "stop task" in this example, only a "stop cycle".

OK I'll try to explain myself better.

I'm just suggesting we should tell users the potential consequences of basing a sub-graph off of a dynamically set cycle point.

Original graph with stop_cycle = 3:

P1 = "foo[-P1] => foo => bar"
R1/3 = "bar => a => b => c & d". # {% set stop_cycle = 3 %}

But if I run this then shut it down while 3/b is running, i.e. part-way through the stop-cycle sub-graph, then I restart it with stop_cycle = 6 - what ends up running is this:

It might be obvious to us that the original stop-cycle sub-graph gets truncated and a whole new one gets based on cycle 6, but I'm not sure it'll be so obvious to all users.

I also think the example should have intercycle dependence (like mine above) and anchor the stop-cycle sub-graph to the main graph (like mine above), so that (in lieu of #5090) the stop-cycle sub-graph runs just before the workflow shuts down at the stop after cycle point, and not earlier than that (i.e. concurrent with earlier cycle points). That would almost certainly be wanted in a real use case.

I'm just suggesting we should tell users the potential consequences of basing a sub-graph off of a dynamically set cycle point.

Gotcha.

The same thing applies to the final cycle point (e.g. R1/$) so should be expected, but fair enough, I'll add a note.

@hjoliver, done.