Document join behavior of fork task

[matthias-pichler]

fork & join

Similar to fork() in programming there is an implicit notion of join() in the workflow DSL. Namely when all branches (of a non-competing fork) finish:

document: {}
do:
  - forkExample:
      branches:
        - a: {}
        - b:
            do:
              - b1: {}
              - b2: {}
        - c: {}
  - d: {}

The corresponding state diagram would look like this:

stateDiagram-v2
    state fork_state <<fork>>
    state join_state <<join>>

    [*] --> fork_state
    fork_state --> a
    fork_state --> b1
    fork_state --> c

    b1 --> b2

    a --> join_state
    b2 --> join_state
    c --> join_state
    join_state --> d
    d --> [*]

Loading

Here the first bar represent a fork and the second a join. Task d would only run after a, b1, b2 and c have finished.

However the current state of the specification does not enumerate all cases, or at least leaves a lot implicitly defined:

then in neighboring branch

The following definition jumps from one (b) branch to another (a):

document: {}
do:
  - forkExample:
      branches:
        - a: 
            do:
              - a1: {}
              - a2: {}
        - b:
            do:
              - b1:
                  then: a2
  - d: {}

stateDiagram-v2
    state fork_state <<fork>>
    state join_state <<join>>

    [*] --> fork_state
    fork_state --> a1
    fork_state --> b1

    state "a2" as a2_l
    state "a2" as a2_r

    b1 --> a2_l
    a1 --> a2_r

    a2_l --> join_state
    a2_r --> join_state
    join_state --> d
    d --> [*]

Loading

In my understanding this would execute task a2 twice and proceed after both branches have finished. Or should something like this be disallowed?

then outside of fork

Another case is when a task outside of fork is referenced in then. Here b references d

document: {}
do:
  - forkExample:
      branches:
        - a: 
            do:
              - a1: {}
              - a2: {}
        - b:
            then: d
  - d: {}
  - e: {}

stateDiagram-v2
    state fork_state <<fork>>
    state join_state <<join>>

    [*] --> fork_state
    fork_state --> a1
    fork_state --> b

    a1 --> a2

    state "d" as d_in
    state "e" as e_in

    a2 --> join_state
    b --> d_in
    d_in --> e_in
    e_in --> join_state
    join_state --> d
    d --> e
    e --> [*]

Loading

In my understanding this would execute the whole chain of d --> e twice as illustrated in the state diagram but the second run of d & e would wait for both branches to be done

[cdavernas]

The following definition jumps from one (b) branch to another (a):

That is not possible. The flow is invalid as a2 does not exist in the scope of the do of the b branch

Another case is when a task outside of fork is referenced in then. Here b references d

That is not possible. The flow is invalid as d does not exist in the scope of the b branch.

---

As discussed in the past, you can only flow to a task that is located in the same scope. You cannot, from within a nested task flow to a upper level task.

[matthias-pichler]

@cdavernas

That is not possible. The flow is invalid as a2 does not exist in the scope of the do of the b branch

ok makes sense to me, should this be allowed?

document: {}
do:
  - forkExample:
      branches:
        - a: 
            do:
              - a1: {}
              - a2: {}
        - b:
             then: a
  - d: {}

[matthias-pichler]

As discussed in the past, you can only flow to a task that is located in the same scope. You cannot, from within a nested task flow to a upper level task.

ok perfect this basically handles all these cases 👍 I think we should then document the notion of a scope and update the docs of the flowDirective to reference this constraint.

[github-actions]

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.