Clarification on supporting multiple actions and actionMode in Operation State

[yzhao244]

I have this issue opened and would like to discuss the spec regarding the clarification on supporting multiple actions and actionMode in Operation state.

If my understanding is correct, in the specifications, the Operation State can contain multiple actions, and each action contains one function or one subflow. However, this approach cannot flexibly specify onErrors definition such as a retry policy for each action.

Furthermore, I looked a closed issue which has similar topic discussed before 140 . @tsurdilo @manuelstein @cathyhongzhang Thanks for the input of that issue, it was helpful for me to clarify some things. :)

However, I am still trying to clarify what are the use cases of using multiple actions in one Operation State vs simply using multiple Operation States which gain the flexibility of specifying onError definition for each function. When I looked at AWS Step Function which has similar concept called "Task" (I think it is quite equivalent to Operation) can only contain one function where user can specify retry definition for each function.

Therefore, it may be confusing to new users who are not fully aware of pros and cons about using multiple actions which lose the flexibility of specifying retry policy for each action in Operation State.

It could be just me having this question lol.. I would appreciate if you could please help me out. :)

[tsurdilo]

@yzhao244 this is indeed a workflow definition design choice based on your requirements (whether to have a single function invocation in your actions or multiple).

A State (or Task in ASL as you mentioned) for us represents a unit of work. An action definition can be part of this unit of work, but in some cases you can have multiple actions represent a single one. Error handling in SW currently is based again, on errors raised during unit of work / state execution, and so are retry definitions. So yes, the way of defining a retry definition for a single action (function invocation) is to have a single action associated with your action definition.

Do you have some use cases where you think this is better handled in a different way(s)?

[tsurdilo]

@yzhao244

One more thing - the project github repo is here: https://github.com/serverlessworkflow/specification If you don't mind lets more our conversations there so community can see it better. Ty

[yzhao244]

@tsurdilo I am very sorry that I opened issue here. I will create a new one there and close this one