Add a new suspended workflow status phase

[cdavernas]

What would you like to be added:

Reintroduce the suspended workflow status phase

Why is this needed:

Adds a status phase that clearly describes that the workflow has been manually and explicitly suspended by a user, as opposed to waiting, which describes that the workflow is waiting for event(s) to be correlated.

Additional notes:

The suspended status phase was initialy part of the DSL, but was removed following (very valid) observations from @fjtirado, who considered that waiting could actually represent both phases.

However, following the implementation of the suspend feature in Synapse, we realized that users could not differenciate flows that were explicitly suspended from ones that were being correlated, thus the feature request.

[fjtirado]

ok, so waiting is a "natural" status, the workflow reach it as part of its execution while suspended is "forced" one, explicitly set by the user.
My only concern is that suspending a workflow should not necessarily be implemented by all implementors. I mean, I can foresee an implementation that does not provide ways to suspend workflow execution and its still a compliant one, wdyt?

[cdavernas]

ok, so waiting is a "natural" status, the workflow reach it as part of its execution while suspended is "forced" one, explicitly set by the user.

That's my understanding of it, yes.

I mean, I can foresee an implementation that does not provide ways to suspend workflow execution and its still a compliant one, wdyt?

@fjtirado Very valid point indeed. I personally don't see the requirement of enforcing it. That status phase is IMO a nice to have in case one implements the related feature. Furthermore, adding it would allows us to exhaustively describe all the possible phases of a workflow, regardless of what has been implemented or not.

[fjtirado]

As an alternative, I think we can broadly understand waiting as waiting for something (not just events), so it will also included the state "waiting for the user to eventually resume the workflow he temporalily stopped for some reason" and then let implementors provides "substates" or "states additional description" freely. Because there might be implementations that might want to differentiate between "waiting for event" or "waiting for rest response" and this will allow them to do that.

[fjtirado]

Or following a similar idea, add an additional actor field, which will include the "initiator", human or machine ;), that let the workflow to reach the current state
So in the suspend case, state will be waiting and actor will be user name
In the waiting for event case., state will be waiting and actor will be event type

[fjtirado]

The reason Im proposing alternatives is that once we differentiate between two ways of waiting (waiting to resume after user intervention, suspended, and waiting for an event to arrive as defined in the file, current waiting), more will eventually come up (not necessarily applicable to all implementations, as is the case for suspended), but I maybe wrong and we will just have those two only.