Closed JohnWelborn closed 4 years ago
Mistral apparently is IDLE and reports success. Probably an edge case?
cc: @m4dcoder
mistral workfow which execution is working as expected, all included tasks are performed successfully but the status of the workflow execution shows: “failed”
mab@mab-virtual-machine:/opt/stackstorm/packs/vR5600_IPSec/actions$
cat wf_mistral_simple.yaml
---
mab@mab-virtual-machine:/opt/stackstorm/packs/vR5600_IPSec/actions$ cat wf_mistral_simple.yaml
---
name: "wf_mistral_simple"
description: "Simple Mistral Workflow with Join"
pack: vR5600_IPSec
runner_type: "mistral-v2"
entry_point: "workflows/wf_mistral_simple.yaml"
enabled: true
parameters:
eastDeviceIP:
type: string
description: IP address of East vRouter
required: true
westDeviceIP:
type: string
description: IP address of West vRouter
required: true
workflow:
default: vR5600_IPSec.wf_mistral_simple.main
immutable: true
type: string
notify:
on-complete:
message: '"@channel: Action succeeded."'
routes:
- "slack"
mab@mab-virtual-machine:/opt/stackstorm/packs/vR5600_IPSec/actions$
mab@mab-virtual-machine:/opt/stackstorm/packs/vR5600_IPSec/actions$ cat workflows/wf_mistral_simple.yaml
version: '2.0'
name: vR5600_IPSec.wf_mistral_simple
description: Simple Mistral Workflow with Join.
workflows:
main:
type: direct
input:
- eastDeviceIP
- westDeviceIP
output:
stdout: <% $.stdout %>
tasks:
initial:
action: core.local
input:
cmd: "echo Starting IPSec Configuratiton ..."
on-success:
- east_start_cfg_session
- west_start_cfg_session
on-error:
- fail_status
east_start_cfg_session:
action: "vR5600_base.start_cfg_session"
input:
deviceIP: <% $.eastDeviceIP %>
on-success:
- finished
on-error:
- fail_status
west_start_cfg_session:
action: "vR5600_base.start_cfg_session"
input:
deviceIP: <% $.westDeviceIP %>
on-success:
- finished
on-error:
- fail_status
finished:
join: all
action: core.local
input:
cmd: "echo Configuration Done ..."
fail_status :
action: core.local
input:
cmd: "echo Fail ..."
mab@mab-virtual-machine:/opt/stackstorm/packs/vR5600_IPSec/actions$
It seems that mistral treats join: all
as join: 3
in the case of @JohnWelborn . And if the number of tasks less than 3, it will fail.
Is there any way to let mistral to auto-detect how much tasks run parallel at runtime? Like what camunda dose.
Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.
When doing a mistral join all on upstream tasks where at least one does not run because of yaql logic, it stays in the running state in st2 and never runs the task with the join.