-
Notifications
You must be signed in to change notification settings - Fork 146
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
Define specific rules when merging action output by default #712
Comments
@cdavernas, what we did in Kogito for those cases is to merge the non object json node with a "response" name. |
Just to illustrate using your example, we then have an output like this: {
"someName": "someValue",
"response": [1, 2, 3]
} But it's definitely doable to have a definition at the spec level of what to do in such situations. |
Common sense indeed, but it would imho be nice to specify that in the spec so that users don't "discover" inconsistencies amongst runtimes. |
Oh sure thing, I agree entirely with you. I remember we brought this to discussion, but didn't go further, so we did it by ourselves |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Update specification to make runtimes predicateble when an action produced a non json object and there is not toStateData filter
Update specification to make runtimes predicateble when an action produced a non json object and there is not toStateData filter Signed-off-by: Francisco Javier Tirado Sarti <ftirados@redhat.com>
Signed-off-by: Francisco Javier Tirado Sarti <ftirados@redhat.com>
Signed-off-by: Francisco Javier Tirado Sarti <ftirados@redhat.com>
Signed-off-by: Francisco Javier Tirado Sarti <ftirados@redhat.com>
[Fix #712] Describe merge behaviour for non object
Update specification to make runtimes predicateble when an action produced a non json object and there is not toStateData filter Signed-off-by: Francisco Javier Tirado Sarti <ftirados@redhat.com> Signed-off-by: Charles d'Avernas <charles.davernas@neuroglia.io>
Signed-off-by: Francisco Javier Tirado Sarti <ftirados@redhat.com> Signed-off-by: Charles d'Avernas <charles.davernas@neuroglia.io>
Signed-off-by: Francisco Javier Tirado Sarti <ftirados@redhat.com> Signed-off-by: Charles d'Avernas <charles.davernas@neuroglia.io>
What would you like to be added:
Define specific rules when merging action output by default
Why is this needed:
So far, the spec mandates that the output of an action without
toState
data filter should be merged back 'as is' into the state data.Problem is, if the output of said action is not an object, merging it into state data will effectilvely fault the whole workflow: all evaluations will fail.
Image for instance an action that returns, say, an array or, why not, an integer. Your state was the following beforehand:
After the action, the state data would be:
Or why not something like:
125
Which would result in all further actions to fail. Consider, for example, a next action with a
fromState
data filter => BOOM.What I propose is that the action output be merged back "as-is" ONLY if/when it's an object. If it's an array or a value type (string, bool, int, ...), it should instead be merged back into a 'actionOuput' property, for example. The name of that property could be based on the name of the action, such as
myActionOutput
.WDYT?
The text was updated successfully, but these errors were encountered: