Fix manual triggering of runahead-limited parentless tasks.

[hjoliver]

These changes close #4619

Note: this branch is built on top of #4641 (now merged; rebased onto master)

The problem was, we were not auto-spawning the successor of a manually-triggered parentless task unless runahead limit had been recomputed, and we don't recompute the limit after manual triggering (the limit is irrelevant for that). We need to auto-spawn the successor task regardless, but only release it from runhead if the limit has been recomputed (and if the task is below below the limit, of course).

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg and conda-environment.yml.
• Appropriate tests are included (unit and/or functional).
• Appropriate change log entry included.
• No documentation update required.

[MetRonnie]

Tested out manually, fixes the bug.

Test failure is due to changes in #4641 (comment)

[oliver-sanders]

This does fix the example reported in #4619, however, fails for a slightly more nuanced example.

The test on this branch has three cycles with a runahead limit of 1:

1  # active
2  # trigger this one
3  # workflow should run onto this task

This example works fine on this branch (and on #4621).

If we take this example and trigger the task in cycle 3 instead we create a bigger headache for the Scheduler as it needs to step over cycles 2 & 3 to spawn cycle 4 as runahead before cycle 2 has even run.

1  # active
2  # runahead
3  # trigger this one
4  # workflow should run onto this task

This example does not work on this branch (Scheduler shuts down), however, does work on #4621.

Reopened the original with a modification of the test from this branch to cover the 4 cycle variant.

[edit] Something is wrong with my testing of #4621 branch apologies:eyes:

[MetRonnie]

Can confirm it doesn't work for Oliver's modified case:

[scheduling]
    cycling mode = integer
    runahead limit = P1
    [[graph]]
        P1 = foo
[runtime]
    [[foo]]
        script = sleep 20

$ cylc play workflow
# 1/foo spawns and starts running
# 2/foo spawns in runahead
$ cylc trigger workflow//3/foo
# 3/foo spawns and runs
# When 1/foo, 2/foo and 3/foo finish, workflow shuts down, even though no FCP

[hjoliver]

This test is broken because:

Oops, sorry I had an un-pushed commit fixing the stupid bash syntax errors (and the UID syntax too!).

The intended if syntax was this:

if (( CYLC_TASK_CYCLE_POINT == 1 )); then ...

[hjoliver]

Fixed the new test, checked it passes here and fails on master (and for the right reasons).

[hjoliver]

Can confirm it doesn't work for Oliver's modified case:

Interestingly, it works fine if I trigger any foo with cycle point >= 4 (or 2/foo, on this branch), just not 3/foo.

[hjoliver]

The new example is technically a different problem, so I'll put up a new PR for that ... #4644

Tests all pass; this one is good to go.

[oliver-sanders]

I think this is good, doing some testing with the other PR merged on top...

[hjoliver]

By the way, this branch is equivalent to the approach of #4621 (for triggering runahead tasks only) but this one might have a small efficiency advantage via not recomputing the runahead limit when it's not needed.