Refactor retries

[cdavernas]

What would you like to be added?

Refactor retries

Why is this needed?

Retries are one of the many actions that could be undertaken when an error is caught.

The current retry (strategy) definition should IMO be referenced by an handler that undertakes a retry upon given kinds of error (or upon all errors, possibly except some). It actually mixes both the handler and the retry concerns, and as such limit possibilities that we could open with my proposal.

What is your proposal?

Create a new errorHandler definition, that would allow users to define the errors they want to catch (or not to catch) and how they want to react (or not to react) to them.

An errorHandler could look like the following:

name: on-503
catch:
  when: 
    #type: https://fake.hotel.com/errors/bookings/failed
    status: 503
    # title: NotAvailable
    # condition: ${ jqexpression }
  #whenNot:
  #...
then:
  continue: true #continue the flow as if nothing happened
  #retry:
  #  policy: my-retry-policy
  # end: true
  # compensate: true

An action could then reference it like so:

actions:
  - name: my-action 
    functionRef: my-first-action
    onError:
      - on-503

[ricardozanini]

cc @fjtirado

[lsytj0413]

It's seems like this is another style of error representation as which describe in #770 . Should we keep use an unified representation？

[cdavernas]

@lsytj0413 No, not really, though the two issues are undeniably linked.
#770 intends to refactor the way runtimes should represent an error, while this one is about how to handle (and what we can do with) it, when produced by either runtimes or some kind of throw mechanism like proposed in #771

I chose to split it in 2 different issues for the sake of simplicity and in order to avoid following God PRs.

Does that make sense to you?

[cdavernas]

Closed as resolved by 1.0.0-alpha1, and therefore as part of #843