Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge behaviour #837

Closed
fjtirado opened this issue Apr 5, 2024 · 2 comments
Closed

Merge behaviour #837

fjtirado opened this issue Apr 5, 2024 · 2 comments
Assignees

Comments

@fjtirado
Copy link
Collaborator

fjtirado commented Apr 5, 2024

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 #832 (comment)

@ricardozanini
Copy link
Member

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

@cdavernas
Copy link
Member

cdavernas commented May 17, 2024

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 🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants