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

Allow custom reduction policy for CompositeNode #129

Open
marcinus opened this issue Mar 16, 2020 · 0 comments
Open

Allow custom reduction policy for CompositeNode #129

marcinus opened this issue Mar 16, 2020 · 0 comments

Comments

@marcinus
Copy link
Contributor

marcinus commented Mar 16, 2020

Is your feature request related to a problem? Please describe.

  • Imagine you call 3 different services, but one of them fails. They are called in parallel, but failure of this one in particular could be handled nicely (say it's just logging).
  • Or imagine you're calling a number of services, but you're interested only in the first one that responds.

However, the transition resulting from CompositeNode is _error whenever any of subnodes ends with transition different than _success. Also, whenever subnodes are executed, the executions waits for all of them to complete.

Describe the solution you'd like
Ability to specify reduction strategy for CompositeNode:

actions = [
   { action = serviceA }
   { action = serviceB }
   { action = serviceC }
]
reduction = first
transition {
  _success = [
    { _success, _success, _success }
    { _success, _success, _error }
  ]
  defaultTransition = _error
}

The logic for selecting transition could be further enhanced, e.g. placeholders for any transition?

Describe alternatives you've considered
There is no way to achieve this reduction = first strategy without writing a custom Action (that could potentially use HttpAction underneath).
Also, the information about each subnode's individual execution transition is lost in the current setup.

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

No branches or pull requests

1 participant