Conditional tasks and their transitions

[JBBianchi]

Hello folks,

I'm not sure I have the right understanding of tasks transitions when they are skipped.

From my understanding of the docs, if the if condition is not met, the task is skipped and its output becomes its raw input. Therefore, if I follow the logic of the data flow graph, the rest of the logic should apply and the flow directive should still be respected.

For instance, given the tasks list:

do:
- setFoo:
    if: $input.keyword == 'foo'
    set:
      foo: true
    then: conditionalFoo
- setBar:
    if: $input.keyword == 'bar'
    set:
      bar: true
    then: conditionalBar
- conditionalFoo:
    if: $input.foo != true
    set:
      anwser: 0
    then: finalTask
- conditionalBar:
    if: $input.bar != true
    set:
      anwser: 42
    then: end
- finalTask:
    set:
      anwser: final

If the workflow input is keyword: foo, setFoo is executed, then conditionalFoo is skipped and respecting its flow directive, finalTask is executed, therefore the output of the workflow is anwser: final.

If the workflow input is keyword: bar, setBar is executed, then conditionalBar is skipped and respecting its flow directive, the workflow ends, the output is bar: true. setFoo is skipped but its flow directive is respected, then conditionalFoo and finalTaskis executed, therefore the output of the workflow isanwser: final. The setBar` "branch" is never executed as there is no flow directive to reach it.

Is it the proper way of thinking about conditional tasks ?

As a side question, should the output transformation be skipped or not ? (orange or red arrow ?)

[matthias-pichler]

Very valid points! I think the source of ambiguity is that there are multiple ways of doing flow control: i.e. if, (switch) & then. (I can absolutely understand their respective benefits and therefore am NOT advocating for removing anything. 😅 ) I also feel like this has no "correct" answer.

In my opinion:

When if evaluates to false the "task execution" is skipped. This means that:

1. the input transformation is skipped
2. the output transformation is also skipped*
3. the flow directive in then is honoured

* skipping the output transformation simplifies the expression because otherwise one would have to handle both the raw task output (eval(if) == true) and the raw task input (eval(if) == false). This would make the expressions very cumbersome to write

[cdavernas]

@matthias-pichler I agree with you concerning 1 and 2, but not regarding 3. IMHO, if the task is skipped, so should its then directive. It would allow authors to conditionally end the flow. Honoring the then directive can introduce wierd, counter intuitive behaviors, such as in the following example:

do:
  - registerUser:
      call: http
      with:
        uri: https://sample-api.com/users/register
        method: post
        body:
          firstName: John
          lastName: Doe
          email: john.doe@email.com
  - throwIfAlreadyRegistered:
      if: '.registration.outcome == "Failed" and .registration.statusReason == "User already exists"'
      set: {}
      then: end
  - sendConfirmationEmail:
      ...

In above example, I'd personally expect the sendConfirmationEmail task to be executed if the throwIfAlreadyRegistered has been skipped, instead of ending the flow.

[JBBianchi]

I must admit it's a tricky one but after giving it some thoughts I'd rather agree with @matthias-pichler.

if should be used for conditional execution, not to impact the flow. switch should be used instead in that case.

For instance, your example should use a switch instead of if because you actually want to change the flow depending on a condition, not act upon it, if it makes sense.

A similar use-case that benefit from if would be:

do:
- getUser:
      call: http
      with:
        uri: https://sample-api.com/users/{email}
- registerIfNotExist:
      if: '.user == null'
      call: http
      with:
        uri: https://sample-api.com/users/register
        method: post
        body:
          firstName: ${ $workflow.input.firstname}
          lastName: ${ $workflow.input.lastname}
          email: ${ $workflow.input.email }
- sendNotification:
    # ...

In this example, the if makes the task "optional", it could be skipped without having an impact on the flow.
(A more realistic example for the use-case above should rather rely on try as the first task would probably return a 404 instead of a 200 with an empty user. But that's not the scope of this discussion.)

For the use-case you described, I think the switch way would make more sense:

do:
  - registerUser:
      call: http
      with:
        uri: https://sample-api.com/users/register
        method: post
        body:
          firstName: John
          lastName: Doe
          email: john.doe@email.com
  - endIfAlreadyRegistered:
      switch:
        - endCase:
            when: '.registration.outcome == "Failed" and .registration.statusReason == "User already exists"'
            then: end
  - sendConfirmationEmail:
      ...

Does it make sense or am I missing anything ?

[cdavernas]

For the use-case you described, I think the switch way would make more sense:

I strongly disagree here. Switch is imo intended for multiple cases. Here there's a single once, thus the if makes more sense to me. Single case switch looks wierd to me. Plus, my proposal imho perfectly simulates what you'd be able to do in any programatic language (i.e. a return in a if is only executed if the if block is entered)