There is a case where adding a wait_for for outputs only, without specifying outputs.success causes the workflow to fail, but it's only detected by the fallback failure detection.
To reproduce
Here is a workflow that sometimes reproduces this:
version: v0.2.0
input:
root: WorkflowInput
objects:
WorkflowInput:
id: WorkflowInput
properties:
step_1_enabled:
type:
type_id: bool
step_2_enabled:
type:
type_id: bool
steps:
wait_1:
plugin:
src: "n/a"
deployment_type: "builtin"
step: wait
input:
wait_time_ms: 0
enabled: !expr $.input.step_1_enabled
wait_2:
plugin:
src: "n/a"
deployment_type: "builtin"
wait_for: !expr $.steps.wait_1.outputs # Changing this to outputs.success does not have the same problem.
step: wait
input:
wait_time_ms: 0
enabled: !expr $.input.step_2_enabled
outputs:
all:
simple_wait_output: !oneof
discriminator: "result"
one_of:
a:
simple: !expr $.steps.wait_2.outputs.success
sub_oneof: !oneof
discriminator: "sub-result"
one_of:
# Use the same IDs to test for conflicts.
a: !expr $.steps.wait_1.outputs.success
b: !expr $.steps.wait_1.disabled.output
b: !expr $.steps.wait_2.disabled.output
`
With inputs:
map[step_1_enabled:true step_2_enabled:true]
Additional context
This is on the development branch for oneof outputs.
Describe the bug
There is a case where adding a wait_for for
outputs
only, without specifyingoutputs.success
causes the workflow to fail, but it's only detected by the fallback failure detection.To reproduce
Here is a workflow that sometimes reproduces this:
With inputs:
Additional context
This is on the development branch for oneof outputs.