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
730 stars 146 forks source link

Merge behaviour #837

Closed fjtirado closed 3 months ago

fjtirado commented 5 months ago

What would you like to be added: Discuss about proper merge behaviour of action results. Currently actions results are merged to the model by default. This is problematic for actions within forEachState. Also for intermediate actions within an operation state (when normally you want to feed the next action with the result of the previous one, but without adding it to the model). However, merging the result of the action to the model makes perfect sense for operation states with just one action.

Having into account this rationale. I propose to not merge into the model any action result , except if the action is the last one of an operation state, an event state or a parallel state branch. Also I propose to add a new context variable $WORKFLOW.prevActionResult, which contains the result of the previous actions, so chain of actions can communicate between without actually merging data into the model

Why is this needed: This is a follow up of https://github.com/serverlessworkflow/specification/pull/832#discussion_r1531698141

ricardozanini commented 3 months ago

@cdavernas @fjtirado let's use this issue to address the solution in 0.10.

cdavernas commented 3 months ago

Closed as part of #843.

As of now, the data flow is sightly different in the 0.10, and does not need default merge behavior to be defined, as output does not need to be a map (as opposed to context/scope data, which is a key/value map of contextual/scoped data shared accross tasks). This ensure easier understanding/handling of flow, which is just a sequence of input/output, while providing the shared data bag approach that state data represent in 0.9-.

This can obviously be changed, but I start doing so in 1.0.0-alpha1, so that we dont have to refactor the refactor 🤣