Hilary James Oliver

OK, sorry if I didn't read the fine print: > Cylc 7: Spawns both the f and b chains. I guess I over-interpreted this, and that it "worked in Cylc...

> Should we even allow a workflow to be started if it contains unreachable sections of graph? Probably not, but (obviously) achieving that requires being able to detect that at...

This is a known feature, and not a bug (not that you are definitely saying it is a bug!) but I agree some users will be surprised by it. What...

(Note I've just fixed a typo in description ("failed `a`" should have been "failed `b`"; and clarified the `# comment`). (I haven't read your comment just above yet)

Apologies, I posted this just before going on leave and didn't get chance to clarify and respond to comments. Back now! Also I should have added the "question" label myself...

@TomekTrzeciak - > > > Why would that need to be an error? I would expect the --flow=something option to take effect regardless of the task being in the pool...

Yes, once per message regardless of comms method is the desired behavior. Note, on current master: - duplicate polled output messages do not re-trigger the downstream task (which wouldn't work...

Since spawn-on-demand implementation, a workflow that only has dependencies like this will shutdown immediately on startup without doing anything (Cylc 8) rather than start up and immediately stall (Cylc 7)....

This seems to have risen in importance again, because of the arguably-correct but also arguably-unhelpful "premature shutdown" effect in Cylc 8. So if we do this, note from my original...

Yeah I commented on that on the thread (before I saw your response here). I think that's fine so long as users understand: - why it works - why that...