workflow-state: handle submitted as a message/trigger not status

[oliver-sanders]

The workflow-state command defaults to polling task status rather than task trigger.

The CLI upgrade advise tells you to upgrade an existing message poller into a status poller:

$ cylc workflow-state generic --point 20191209T1200Z --task bar --message=submitted
WARNING - --task, --status, --message, --output, --point, --task-point are deprecated. Please use an ID:
    generic//20191209T1200Z/bar:submitted

This is inconsistent with the xtrigger upgrade advice which tells you to use is_message=True:

        workflow_state(message=submitted, point=1234, task=foo, workflow=ab) -->
    workflow_state(workflow_task_id=ab//1234/foo:submitted, is_message=True)

The CLI advice becomes a problem in the case of the submitted output. Because submitted is a status, it defaults to status polling. However, the submitted status is transitory so this test is not safe.

Suggest:

• Changing the CLI upgrade advice to match the xtrigger advice.
• Raising a warning if workflow status polling is configured for non-final statuses.
• Document trigger polling as the preferred approach.

[hjoliver]

I commented on this in the recent workflow-state overhaul PR, here:

#5809 (comment)

Initially I did automatically convert transient statuses to outputs, but backed out of that for the following reasons:

• the command and xtrigger names (-state) suggest status should be the default (outputs were latecomers to this functionality)
• continuity with all prior usage
• it might be surprising if a user asks for :running (status) and gets :started (output)
• it seems possible that the user only wants to know the instantaneous status

Maybe that was the wrong call, but @MetRonnie seemed satisfied at the time.

[hjoliver]

The CLI upgrade advise tells you to upgrade an existing message poller into a status poller:

Definitely not deliberate.

Suggest:

Agreed on all counts.