How to handle results of Actions in states such as OperationState

[globalflea]

In the specs, several states (e.g. Operation) allows an array of actions to be performed but does not (i think) say anything about how to handle the returned array of responses (i assume one for each action).

How would i treat this array of responses?
A. Merge all json data into one? and then,
A.1. Do i apply the action's results filter to each individual before merging or apply the filter to the final merged response
A.2. How do i handle if the two or more results data conflict during merge - which will take precedence? E.g R1 = { "name": "tom"}, R2 = {"name": "joe"}

B. Do not merge the array of responses,
B.1. Do i apply the State output filter to all responses individual and merge the results before passing it on?
B.1.a. Then as with earlier question, how to i handle conflict of responses (see A.2)
B.2. If i pass the array of responses to the next state or workflow, how is the state suppose to handle it. The specs seems to say there's only a single input/output from the various states

Thanks

[manick02]

Have a look at this sample, https://github.com/serverlessworkflow/specification/blob/main/specification.md#using-multiple-data-filters. Each Function/Operation can specify a toStateData filter. This is not an answer to your question, but may give bit more clarity for what you are looking

[tsurdilo]

@globalflea to add to @manick02 response, there is a number of questions here so will address them individually:

states (e.g. Operation) allows an array of actions

Actions array defines functions (actions) that need to be invoked during workflow execution
by default actions are executed sequentially, but you can use the "actionMode" property to set that execution in parallel.

As soon as the action (function invocation) completes, and has a result, it should be merged into states data. So if you have a sequential actionMode, and 2 action definitions inside the actions array you should have the following sequence:

1. Function 1 invocation
2. Function 1 results are merged
3. Function 2 invocation
4. Function 2 results merged

In case of parallel actionMode, its similar except it happens as soon as the parallel action invocation produces a result, until all parallel function invocations are completed.

By default, each actions "data input" is the current state data (state data right before the action/function is scheduled to be in invoked.
By default each action/function invocation results are merged with the top-level state data element (".").

You can have control over this default behavior with action data filers.
Action data filers have 3 properties:
fromStateData
results
toStateData

Action data filers are per-action so you have to currently define them for each of your actions. I think it would be good to add a default action data filer for all actions (please raise an issue for this :))

Let's look how action data filers come into play:

1. fromStateData - expression which is evaluated before the action is invoked. It filers the states data to provide only a sub-set of data that can be used as input to the action (for its parameter defs for example)
2. results - expression that can filter the action results before its merged into the state data. This is evaluated after the action/function returns a result.
3. toStateData - expression that selects a node in the states data where the action/function results should be merged into. This is also evaluated after action/function returns a result and after "results" expression is evaluated.

Hope this helps.

Now from this i see three improvements we can do in the spec, please open issues for those in the spec repo:

1. Add default action filer for all actions (so they dont need to be defined for each one if same should be used)
2. Add ability in actions to specify that action/function results should be ignored (not merged with state data)
3. Improve the specification document to give more details on this as its currently not enough info)

[tsurdilo]

Just to add, this will change a little when we introduce async action/function executions, just FYI. Currently all actions that be sequential or parallel execution are assumed to be sync invocations with the spec, meaning they wait for a result after invoked

[tsurdilo]

How would i treat this array of responses?
A. Merge all json data into one? and then,
A.1. Do i apply the action's results filter to each individual before merging or apply the filter to the final merged response
A.2. How do i handle if the two or more results data conflict during merge - which will take precedence? E.g R1 = { "name": "tom"}, R2 = {"name": "joe"}

A. Answered in previous post, for sequential invocations its done one after the other, for parallel, as soon as one action completes
A.1. Also answered in previous post I think, let me know if there are further questions on that
A.2. Yes conflicts can happen, and just like in code, using the "toStateData" property on action data filer you can/have to control where the results go into.

[tsurdilo]

B. Do not merge the array of responses,
B.1. Do i apply the State output filter to all responses individual and merge the results before passing it on?
B.1.a. Then as with earlier question, how to i handle conflict of responses (see A.2)
B.2. If i pass the array of responses to the next state or workflow, how is the state suppose to handle it. The specs seems to say there's only a single input/output from the various states

B. Yes there is currently no way to specify that (see earlier reply to raise an issue in the spec repo for that). Currently its assumed if action/function has no results then there is nothing to be merged, but thats not enough.
B.1, B.1.a. Believe answered in previous answers, let me know if there are further questions
B.2. Yes, each state has a single input (if starting state the initial workflow data input) or the output of the previous state that is transitioning to it (via explicit transition, or in case of compensation by the compensatedBy prop). Note that the states data is JSON and it should have (its defined in spec) an object type "{}" so you can add many array types inside of it, without issues.

[globalflea]

On a separate note, the spec says action can be function (function ref) or event or subflow by stating at least one must be defined. However, does it mean it can be all three or two can be defined - e.g the action can be both function, event at the same time and I need to do both?
Or the intention is that an action can only be one of function, event, subflow. Ie they are exclusive

[cdavernas]

It can be only one of ;)

[globalflea]

Thanks for the clarification