search

serverlessworkflow / specification

Contains the official specification for the Serverless Workflow Domain Specific Language. It provides detailed guidelines and standards for defining, executing, and managing workflows in serverless environments, ensuring consistency and interoperability across implementations.
http://serverlessworkflow.io
Apache License 2.0
742 stars 147 forks source link

What is the purpose of the `terminate` parameter in the End Definition? #231

Closed alankm closed 3 years ago

alankm commented 3 years ago

What is the question:

What is the purpose of the terminate parameter in the End Definition?

"If true, completes all execution flows in the given workflow instance"

My understanding is that a workflow instance can only be in one state at a time. Some states do perform some degree of parallel logic, but even those have to wait for every branch to end before the implementation should handle the "end".

I suppose n-of-m Parallel states can explicitly end before every branch returns, but I'd have thought what happens to these excess branches should be left up to the implementation so long as it has zero impact on the workflow instance itself.

tsurdilo commented 3 years ago

@alankm i will add a big section on workflow isolation and workflow instances in the near future which will explain all of this. This will also introduce "adhoc" property for workflow definitions which will make things with "default" and "terminate" end defs much clearer as well.

Long story short, the "default" end event completes the execution of a particular workflow path. If there are other paths still active (parallel state executing two branches at a time), that other path can still be active and complete. Once there are no "active" paths the workflow instance can fully complete.

With "terminate", you are terminating the workflow instance once such end state is reached, meaning if there are any other active paths at that time, those are terminated as well.

With "adhoc" this behaviour is slightly different, but I will explain all when I get to it. Hope this helps for now.

alankm commented 3 years ago

@tsurdilo "switch with multiple paths"... Are you suggesting that an event switch should continue listening to events even after switching?

Looking forward to the upcoming section on workflow isolation and workflow instances, because right now I still can't see what this is for.

tsurdilo commented 3 years ago

@alankm sure thing. with addition of "adhoc" terminate end defs will become really important as that will be the only way to terminate a workflow instance...will ping you to review pr

tsurdilo commented 3 years ago

@alankm I will do the mentioned work as part of https://github.com/serverlessworkflow/specification/pull/223 this pr is still work in progress, i still need to update the end definition section and add 2 examples in our examples doc.

If you can please start looking at this pr, especially the "core concepts" sections and the update of the start definition (addition of "adhoc") and let me know what you think of it so far.

tsurdilo commented 3 years ago

@alankm https://github.com/serverlessworkflow/specification/pull/223 is completed now, and it should pretty much explain the question in this issue.

alankm commented 3 years ago

@tsurdilo I've left a comment on #223

I still can't think of a good use for this stuff. Nearly everything in that pull request is already possible in ways that I find simpler, clearer, and more intuitive. I think workflows should end when they end, never loop.

manuelstein commented 3 years ago

@alankm I think the discussion got a bit side-tracked and I'm glad we're having it. To your original question, I think we can improve on the wording of it. So it currently says

If true, completes all execution flows in the given workflow instance

To my understanding, marking a state as terminating the workflow instance means that after that state has completed, the instance is removed - i.e. all the context data can be discarded. When there's correlation, multiple invocations can be correlated on the same workflow instance, i.e. an event can re-enter an existing workflow instance. But when a state is reached that terminates it, then the instance is subsequently removed.

Would it be less confusing if it said:

If true, terminates the workflow instance after the completion of this state

But this wording would conflict with compensation, which triggers a series of compensating states (to my understanding after this state). Can anyone think of a better description?

manuelstein commented 3 years ago

Maybe we're lacking terminology. We could introduce "invocation" as "an activation of the workflow. An invocation may correlate with a previous invocation, in which case the workflow should start with workflow data containing the outcome of the previous invocation."

tsurdilo commented 3 years ago

@manuelstein this is all included in the pr https://github.com/serverlessworkflow/specification/pull/223 maybe we can look.

Regarding compensation, it is explicitly defined, just like the terminate end event, and i think it states that compensation is done "before the state completes", so i think there is no overlap in the two.