Describe the bug
The action executor currently dispatches and tracks work per (command, target) pair rather than per playbook step invocation. This makes it hard to reason about a step as a single unit of work, and causes real bugs around re-execution: pending-interaction/manual-step state is keyed in a way that a step re-run (e.g. retry, or a race between two invocations) can clobber or duplicate in-flight state instead of being tracked per invocation.
This last part is mainly caused by using (ExecutionId, StepId) as a unique identifier. It is used like this for manual steps, but also for reporting.
For linear playbooks, this is ok, but if there is a loop that causes a specific step to execute multiple times, funny things happen. Reporting is keyed of (ExecutionId, StepId) and subsequent report updates of the same step will be silently ignored (if I looked at the code correctly).
Also parallel branches (which can happen if the parallel step is implemented as requested in #156), would lead to the same problem.
To Reproduce provide details logs and steps
This should happen if you use a while step, which is currently implemented.
Expected behavior
Each step invocation should be tracked as its own unit (a stepwise execution model), with a stable per-invocation identifier, so concurrent or repeated executions of the same step never share or overwrite each other's state.
This means introducing a StepExecutionId, next to the ExecutionId to uniquely identify the execution of a specific step.
This has been implemented in hidde-jan#3 , along with some additional improvements to how manual steps are managed.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment information
For example, docker deployment, native run (platform).
Additional context
I created an analysis of the execution model in this PR:
hidde-jan#1
Describe the bug
The action executor currently dispatches and tracks work per (command, target) pair rather than per playbook step invocation. This makes it hard to reason about a step as a single unit of work, and causes real bugs around re-execution: pending-interaction/manual-step state is keyed in a way that a step re-run (e.g. retry, or a race between two invocations) can clobber or duplicate in-flight state instead of being tracked per invocation.
This last part is mainly caused by using (ExecutionId, StepId) as a unique identifier. It is used like this for manual steps, but also for reporting.
For linear playbooks, this is ok, but if there is a loop that causes a specific step to execute multiple times, funny things happen. Reporting is keyed of (ExecutionId, StepId) and subsequent report updates of the same step will be silently ignored (if I looked at the code correctly).
Also parallel branches (which can happen if the parallel step is implemented as requested in #156), would lead to the same problem.
To Reproduce provide details logs and steps
This should happen if you use a while step, which is currently implemented.
Expected behavior
Each step invocation should be tracked as its own unit (a stepwise execution model), with a stable per-invocation identifier, so concurrent or repeated executions of the same step never share or overwrite each other's state.
This means introducing a StepExecutionId, next to the ExecutionId to uniquely identify the execution of a specific step.
This has been implemented in hidde-jan#3 , along with some additional improvements to how manual steps are managed.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment information
For example, docker deployment, native run (platform).
Additional context
I created an analysis of the execution model in this PR:
hidde-jan#1