St2: Orquesta with-items bug

[trstruth]

SUMMARY

In an orquesta workflow, when a task defines a with key, if some tasks in the iteration fail, the behavior from when: <% failed() %> is bugged. More specifically, occasionally the next task will not be executed, and the workflow will be stuck in a running state.

ISSUE TYPE

• Bug Report

STACKSTORM VERSION

root@5ce0d9e5c022:/# st2 --version
st2 2.10.1, on Python 2.7.6

OS / ENVIRONMENT / INSTALL METHOD

docker, installed by following instructions at https://github.com/StackStorm/st2-docker

STEPS TO REPRODUCE

I have created a pack with a workflow that demonstrates this here. The workflow takes an array of numbers as input, and uses with items to pass each number to a python action that will succeed if the number is even, fail if the number is odd.

• st2 pack install https://github.com/trstruth/wib
• st2 run -a wib.wib numbers=1,2,3,4 (execute this about 20 times, as results are inconsistent)

EXPECTED RESULTS

All workflows should succeed fairly quickly, and their output should be as such:

ACTUAL RESULTS

Here is a screenshot of st2 execution list: The first 10 executions are with numbers=1,2,3,4 the last 10 are numbers=1,2,3

Some workflows get stuck in a running state, despite all of the with-items tasks completing:

[Kami]

Thanks for reporting this and taking the time to also create a sample workflow which reproduces the issue :+1:

We will have a look as soon as we get a chance.

[m4dcoder]

We were able to reproduce this with a much simpler workflow. This bug maybe related to how we handle conflict management when writing item result to the database. We currently have a separate issue opened at https://github.com/StackStorm/orquesta/issues/125 to refactor how we handle DB write conflicts. The fix to this other issue may also resolve this problem. Let us fix that other issue first and we will come back and verify this. Our plan is to address these issues before our GA for orquesta at st2 v3.0.

version: 1.0 tasks: task1: with: <% range(0,10) %> action: core.local cmd="exit $((RANDOM %2))"

[m4dcoder]

The bug tagged above is unrelated to this issue.