Make use of arrays of tasks whenever a single task is expected

[cdavernas]

Context

@fjtirado proposes turning single tasks defined by a For/Do and by a Try into arrays of tasks. The main concern is having the same keyword behaving in a different way based on its context (ex: a top level do defines an array, whereas a For/Do requires a single task).

@cdavernas maintains that this defeats the concept of the composite task, and will become problematic if new properties are to be added to a 'sequential' task list. Furthremore, it will make the flow less obvious (implicitly sequential list) and less ubiquitous.

[fjtirado]

My main concern is that do: is logically inconsistent because it currently have two different meanings depending on its position.
Also I feel we are introducing this internal inconsistency just because a not really tried guess (that loops taks are going to be just one)
Also I believe that the new alpha DSL was a subject of flient discussion and I am surprised any change that is not a perceibed bug requires eternal discussion (which jeopardize my implementation work)

[cdavernas]

So the issue is less with array into try or for, but rather that we use a better keyword for For/Do?

[cdavernas]

If so, I'm game as of now.

[cdavernas]

I am surprised any change that is not a perceibed bug requires eternal discussion (which jeopardize my implementation work)

I'd recommend you count every single comment you mentionned that issue on, on both Slack and GitHub, and you might realize that you are the one to flooding communications, just because there's a term you don't like, and feel it makes the schema inconsistent.

It's not a bug, it's an inconsistency, as you said. It's normal to address that inconsistency in a dedicated issue.

It's also acceptable that people have different opinion that yours, and try to counter the flood.

Again, all that is being asked is consensus, as per governance.

[fjtirado]

The reality is that I opened the do: dicussion following your instructions and I not received any single comment for a week (till @matthias-pichler-warrify realized that not all parsers keep the map sequential order). Basically the same thing for the change of expression markup character (however since you like the implicit evaluation, that was quickly added to the schema) and the shell removal issue (which is hanging there)

[cdavernas]

The reality is that I opened a dicussion following your instructions and I not receved any single comment for a week

Yes, and I'm sorry about that. But I knew it would take a lot of energy, and I have a work and, aside from contributing to https://github.com/serverlessworkflow/synapse/tree/1.0.0-alpha1.

That does NOT justify flooding every single channel with your opinions. And does not justify the way you talk oftentimes.

[JBBianchi]

I see the point of @fjtirado and the confusion that can be induced by two different dos. I also understand it can be frustrating to have a lot of discussion on things that may seems trivial, but that's the price to pay for community projects I guess. As in any democratic process, there is a lot of time spend in exposing ideas, discussing them, and in the end, the decision taken might not please every one but just the majority.

That being said, an alternative comes to my mind. I'm throwing it here, not sure it's worth anything but at least it'll be out there:
We could refactor both do and composite in the following way:

• do should always be a single task
• composite loses the execute keyword, we use sequentially | concurrently | compete straight away for a list of tasks

So a single task workflow/for would be something like:

document:
  #...
do:
  call: http
  with:
    method: get
    endpoint: https://petstore.swagger.io/v2/pet/{petId}

And anything with more than one task:

document:
  #...
do:
  sequentially: # or concurrently or compete
    - bookHotel:
      call: http
      with:
        method: post
        endpoint: 
          uri: https://fake-booking-agency.com/hotels/book
          authentication: fake-booking-agency-oauth2
        body:
          name: Four Seasons
          city: Antwerp
          country: Belgium
    - bookFlight:
      call: http
      with:
        method: post
        endpoint: 
          uri: https://fake-booking-agency.com/flights/book
          authentication: fake-booking-agency-oauth2
        body:
          departure:
            date: '01/01/26'
            time: '07:25:00'
            from:
              airport: BRU
              city: Zaventem
              country: Belgium
          arrival:
            date: '01/01/26'
            time: '11:12:00'
            to:
              airport: LIS
              city: Lisbon
              country: Portugal

wdty ?

[cdavernas]

I think it's actually a great idea.

• It allows running tasks in parallel, which is a feature that was not available only at top level (speaking of inconsistencies).
• It's super sexy

[matthias-pichler]

Honestly I think this is brilliant! I really like it 👍

[fjtirado]

@JBBianchi +1 for me

[cdavernas]

@JBBianchi +1 for me

[JBBianchi]

I see @matthias-pichler-warrify suggested something similar in #875 (comment)

[cdavernas]

Ladies and Gentlemen, it seems we reached a consensus!

[ricardozanini]

+1 from my side then :)

(I won't say you will have to wait for my TZ to discuss, I'm just happy we wrapped up once I woke up!) 😛

[matthias-pichler]

I think #882 is ready for review 🚀