stop: fix tracebacks

[oliver-sanders]

• Closes cylc stop traceback #4758

[hjoliver]

If I try to stop two non-existent workflows on this branch:

$ cylc stop foo bar
foo
Done
bar
Done

Shouldn't we distinguish between stopped and not even installed?

In this case, the ServiceFileError is caught and raised as WorkflowStopped in network/__init__.py by the get_location function, without checking the workflow is actually "stopped", or at least installed.

[oliver-sanders]

In this case, the ServiceFileError is caught and raised as WorkflowStopped in network/init.py by the get_location function, without checking the workflow is actually "stopped", or at least installed.

This behaviour is a bit of a pain, e.g. #4748.

Perhaps we should update this logic to raise a "workflow does not exist error" (note this will be raised by orphan jobs left running after the workflow is removed)

[MetRonnie]

Other than Hilary's comment, manually testing ok. Perhaps a functional test would not go amiss?

[oliver-sanders]

Drafting this whilst I ponder on the consequences of changing the exception to handle the workflow does not exist case.

[oliver-sanders]

On a job host with communications method = poll it is not really possible to tell whether the workflow is running or not, or whether it even exists on the workflow host which makes it hard to truly differentiate these error cases.

That said, if possible it would be good to differentiate in this case, e.g. consider a workflow with "broadcast" tasks being ported to a polling job host. The error WorkflowStopped would not lead the porter to the issue.

[oliver-sanders]

Telling stopped from non-existent workflows, whilst simple in some cases is tricky in others and somewhat off topic for this issue.

Would be nice to do, one of the possible advantages would be assisting the porting of workflows to polling job hosts where cylc commands will currently fail with a confusing WorkflowStopped message.

Unfortunately in light of the above it might not be possible without changing the way we manage polling job hosts I.E. putting back the contact2 file to allow them to tell when the parent workflow is running. This would work, but with the caveat that if the scheduler is killed or fails to remote-tidy it will continue to look like it's running from the remote's perspective (as a polling job host can't just SSH back to the scheduler host to check if it's still running, if we could do that the host would use TCP/SSH+TCP comms).

[oliver-sanders]

Have bumped the rest to an 8.1.0 issue - #4798 - because It's not that quick a fix.

[MetRonnie]

Hasn't changed since my last review, right?

Other than Hilary's comment, manually testing ok. Perhaps a functional test would not go amiss?

[hjoliver]

I'll merge this. Patch coverage is 100% anyway.