An action_loop step must declare until: or while_condition: — the compiler rejects it otherwise:
YAMLCompilerError: action_loop must have either 'until' or 'while_condition'
The condition is then never used. Run, hermetically:
- id: loop
action_loop:
- action: filesystem
parameters: {action: write, path: "out/{{ iteration }}.txt", content: "x"}
until: "false"
max_iterations: 4Expected: 4 iterations (until never satisfied, capped by max_iterations). Observed: 1 iteration, one file. until: "{{ iteration >= 3 }}" also gives 1. So does until: "{{ zzz_nosuch_variable }}" — a name that exists nowhere raises nothing, which is the giveaway: the string is never rendered or evaluated.
_check_termination_condition (control_flow/action_loop_handler.py:392) is written correctly — it builds an eval context from loop_context.to_template_dict() and calls the condition evaluator. Something above it is not reaching that path, or is terminating first.
Consequence for validation: templates in an action_loop's until: are dead text. core/loop_contracts.py currently validates them in the loop's body scope, which is the right answer if the field is ever evaluated, and harmless (no false rejection) if it is not. That choice should be revisited once this is fixed.
An
action_loopstep must declareuntil:orwhile_condition:— the compiler rejects it otherwise:The condition is then never used. Run, hermetically:
Expected: 4 iterations (
untilnever satisfied, capped bymax_iterations). Observed: 1 iteration, one file.until: "{{ iteration >= 3 }}"also gives 1. So doesuntil: "{{ zzz_nosuch_variable }}"— a name that exists nowhere raises nothing, which is the giveaway: the string is never rendered or evaluated._check_termination_condition(control_flow/action_loop_handler.py:392) is written correctly — it builds an eval context fromloop_context.to_template_dict()and calls the condition evaluator. Something above it is not reaching that path, or is terminating first.Consequence for validation: templates in an
action_loop'suntil:are dead text.core/loop_contracts.pycurrently validates them in the loop's body scope, which is the right answer if the field is ever evaluated, and harmless (no false rejection) if it is not. That choice should be revisited once this is fixed.