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

Document join behavior of fork task #1012

Open
matthias-pichler opened this issue Sep 11, 2024 · 5 comments
Open

Document join behavior of fork task #1012

matthias-pichler opened this issue Sep 11, 2024 · 5 comments
Assignees
Labels
area: spec Changes in the Specification change: fix Something isn't working. Impacts in a minor version change.

Comments

@matthias-pichler
Copy link
Collaborator

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
Copy link
Member

cdavernas commented Sep 11, 2024

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
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

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.

@ricardozanini ricardozanini added change: fix Something isn't working. Impacts in a minor version change. area: spec Changes in the Specification labels Sep 17, 2024
Copy link

github-actions bot commented Nov 2, 2024

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.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: spec Changes in the Specification change: fix Something isn't working. Impacts in a minor version change.
Projects
Status: Backlog
Development

No branches or pull requests

3 participants