workflow doesn't go ahead next item in case of concurrency: 1

[freeyssu]

I usually use with - items statement for parallel process. However, a failed job with concurrency: 1 config causes that task cannot go ahead with the remained items.

This is my sampe code. if svr1 is failed, the remained 2 items cannot run as workflow is terminated immediately.
I am wondering this is intended and would like to know a way to avoid this situation.

vars
  - servers: ["svr1", "svr2", "svr3"]

task:
    with:
      items: target_server in <% ctx(servers) %>
      concurrency: 1
    action: pack.action    
    next:
      ....

[nzlosh]

This by design as per the documentation https://docs.stackstorm.com/orquesta/languages/orquesta.html#with-items-model

All action executions must complete successfully for the task to reach a succeeded state. If one or more action executions fail, then the task will result in a failed state.

I am not aware of being able to change this behaviour. A workaround would be to write an action iterator that loops over the list. Here's an example (untested)

vars:
  - servers: ["svr1", "svr2", "svr3"]
  - failed_servers: []
  - server_iter: 0

tasks:
  iterate_servers:
    action: core.noop
    next:
      - do: server_action
        when: <% ctx().server_iter < len(ctx().servers) %>
        publish:
          - server_name: <% ctx().servers[ctx().server_iter] %>
      - do: end_loop
        when: <% ctx().server_iter >= len(ctx().servers) %>

  server_action:
    action: some_action
    input:
      host: <% ctx().server_name %>
    next:
      - do: iterate_servers
        when: <% succeeded() %>
        publish:
          - server_iter: <% ctx().server_iter + 1 %>
      - do: iterate_servers
        when: <% failed() %>
        publish:
          - server_iter: <% ctx().server_iter + 1 %>
          - failed_servers: <% ctx.failed_servers.append(ctx().server_name) %>

  end_loop:
    action: core.local
    input:
      cmd: echo <% ctx().servers %> FAILED: <% ctx().failed_servers %>

[freeyssu]

@nzlosh , thanks for your comment.
Yeah, I fully undrstand that one of item failure in loop causes the entire task failure.

My question is why an item failure in loop brakes the task in case concurrency: 1 is configured.
On the other hand, if concurrency value bigger than 1 (e.g. 2), all items can be executed then workflow marks FAIL result. This is what I expect - running all items even though one of item is failed.

[nzlosh]

I misunderstood what you were actually asking from the initial question. The behaviour you describe seems like it could be a bug. At the very least, a concurrency of 1 should have the same behaviour as any other concurrency value when it comes to executing the list of elements.

[freeyssu]

Yes, so my expectation is

vars
   - servers : ["svr1", "svr2", "svr3"]
   
task:
    with:
      items: target_server in <% ctx(servers) %>
      concurrency: 1
    action: pack.action    
    
    # even if svr1 is fail, workflow should go ahead next item svr2 and svr3. Next, the task is failed after all items in loop completes.