Stall when task has parents in some cycles but is parentless in others

[MetRonnie]

From @hjoliver at https://cylc.discourse.group/t/mixing-cycle-and-interval-scheduling-results-in-stall/1299/2:

I think you have uncovered some kind of a bug. I’ve reproduced it, but not had time to figure out what’s going on yet. Here’s a slightly simplified case that gets to the stall faster:

[scheduling]
    initial cycle point = 20230101T18
    runahead limit = P3
    [[graph]]
        PT1H = """
             b => c
             c[-PT1H] => c
        """
        T23 = a => b
[runtime]
    [[a, b, c]]

Result (at 8.6.3)

...
INFO - [20230101T2300Z/c/01:running] => succeeded
INFO - [20230102T0000Z/c:waiting(runahead)] => waiting
WARNING - Partially satisfied prerequisites:
      * 20230102T0000Z/c is waiting on ['20230102T0000Z/b:succeeded']
CRITICAL - Workflow stalled
WARNING - PT1H stall timer starts NOW

The active tasks at this point:

$ cylc dump -t sre
20230102T2300Z/a:waiting (runahead)
20230102T0000Z/c:waiting

The log gives the reason for the stall. But 20230102T0000Z/b should just run automatically, because it doesn’t depend on anything in that cycle.

$ cylc log sre | grep '/b' | grep '=> submitted'
2026-03-17T16:57:00+13:00 INFO - [20230101T1800Z/b/01:preparing] => submitted
2026-03-17T16:57:00+13:00 INFO - [20230101T1900Z/b/01:preparing] => submitted
2026-03-17T16:57:00+13:00 INFO - [20230101T2000Z/b/01:preparing] => submitted
2026-03-17T16:57:00+13:00 INFO - [20230101T2100Z/b/01:preparing] => submitted
2026-03-17T16:57:07+13:00 INFO - [20230101T2200Z/b/01:preparing] => submitted
2026-03-17T16:57:15+13:00 INFO - [20230101T2300Z/b/01:preparing] => submitted

I suspect something is wrong with the code that handles tasks that are parented in some cycles and parentless in others (which is a tricky situation, but I thought we had tests covering it…)

[oliver-sanders]

Is this a duplicate of #5730?

[hjoliver]

I think this probably is a duplicate of #5730 but not 100% sure yet.

[hjoliver]

Tricky to diagnose, because the bug is affected by the runahead limit.

Looking at this rang a bell - I think it relates to how I got parentless tasks working quickly during SoD implementation, for an easy example that I failed to come back to generalize (sorry!).

It works for some parented/parentless task cases but it fails if a parented instance happens to end up at the runahead limit. When that instance is released from runahead it won't spawn future parentless instances, because the parentless spawning code aborts if the instance it is called for is parented.