Invalid `do:switch`

[JBBianchi]

What seems off: After #875, and because of, https://github.com/serverlessworkflow/specification/discussions/884#discussioncomment-9662801, #882 was merged, making do a single task entry. This breaks the possibility to use do:switch as there is nothing to switch to. It forces the user to use do:execute:sequentially:switch.

What you expected to be: We might need to rollback to the original idea of #875, which is to have do as map[string, task], but not only for top level.

Anything else we need to know?: As mentioned by @matthias-pichler-warrify in #875, making do a map[string, task], the execute.sequentially directive doesn't really make sense anymore. We might want to refactor execute at the same time (or keep that for another issue).

[matthias-pichler]

we actually still need to pick a name from:

Create a new fork/branch/multitask/parallelize task, used to define a parallel (and possibly competing) task array

I have a little preference for fork or branch but I don't have a strong opinion about it.

I also prefer fork or branch 👍

[cdavernas]

As said by @matthias-pichler-warrify, both Amazon Step Functions and Google Cloud Workflows use the term "branches" to identify the collections of tasks to run in parallel, so I guess branch is the most adequate term, but I don't have any strong personnal preference.

On a side note for a plausible next good issue is that the branch task should define an array of branch key/value definitions, instead of an array of task key/value definitions. That would allow running branches in parallel, instead of tasks, which I believe is more consistent with what is being proposed here, and would allow defining branch-specific configuration.

branch:
  - branch1:
      - setFoo:
          set:
            foo: bar
  - branch2:
      - setBar:
          set:
            bar: baz

[matthias-pichler]

As said by @matthias-pichler-warrify, both Amazon Step Functions and Google Cloud Workflows use the term "branches" to identify the collections of tasks to run in parallel, so I guess branch is the most adequate term, but I don't have any strong personnal preference.

On a side note for a plausible next good issue is that the branch task should define an array of branch key/value definitions, instead of an array of task key/value definitions. That would allow running branches in parallel, instead of tasks, which I believe is more consistent with what is being proposed here, and would allow defining branch-specific configuration.

branch:
  - branch1:
      - setFoo:
          set:
            foo: bar
  - branch2:
      - setBar:
          set:
            bar: baz

interesting 🤔 that could make a lot of sense and is consistent with switch cases.

on another note the current proposal (I think) includes branch.on ... should I keep it ?

document: {}
do:
  - branchTask:
       branch:
         # compete goes here
         on:
           - task1: {}
           - task2: {}

[cdavernas]

interesting 🤔 that could make a lot of sense and is consistent with switch cases.

👍

on another note the current proposal (I think) includes branch.on ... should I keep it ?

I would then suggest using the term fork for the task, and branches instead of on, which is in my world heavily tight to the concept of events. Also, we would avoid things such as /branch/branches/ which imo is very ugly.

do:
  - branchTask:
      fork:
        compete: true
        branches:
          - task1: {}
          - task2: {}

And that would also set the ground for defining the branch concept proposed in my previous comment.

[fjtirado]

@cdavernas As you mention since order is not relevant for concurrent, we migth write

do:
  - branchTask:
      fork:
        compete: true
        branches:
          task1: {}
          task2: {}

[JBBianchi]

I'm ok with @cdavernas proposal with fork/branches.

@fjtirado suggestion is also valid but I think it can be a bit confusing for the user as task lists are an array everywhere and then in fork/branches, suddenly (even if it's justified), it's an object.

[matthias-pichler]

I'm ok with @cdavernas proposal with fork/branches.

@fjtirado suggestion is also valid but I think it can be a bit confusing for the user as task lists are an array everywhere and then in fork/branches, suddenly (even if it's justified), it's an object.

I also like fork/branches.

@fjtirado the suggestion is valid but a little inconsistent as tasks only appear as arrays now

[fjtirado]

@JBBianchi @matthias-pichler-warrify I agree with you that map is a bit inconsistent with array. No preference from my side, to be honest

[matthias-pichler]

895 should be ready for review 👍