Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

Relationships

#1781 `workflow resume --from` does nothing for forEach steps whose template name contains `${{ }}`

Opened by randybias · 8/22/2026

Summary

swamp workflow resume <wf> --run <id> --from '<template>' is documented to re-expand a forEach step and let each iteration's guard decide. It works for a plain template name (deploydeploy-dev, deploy-qa) but is a silent no-op when the template name contains an expression, e.g. deploy-${{ self.env }} — which is the naming pattern the manual itself recommends ("Resume from a specific step", "Recover forEach iterations").

Steps to reproduce

  1. forEach step named deploy-${{ self.env }} over [dev, qa]; make the qa iteration exit 1.
  2. swamp workflow run wf --input failStep=truedeploy-qa failed, run failed.
  3. swamp workflow resume wf --run <id> --from 'deploy-${{ self.env }}' --input failStep=false
  4. Output shows only downstream jobs re-running; deploy-qa stays failed; run ends failed again. No error, no warning.

Same workflow with the step renamed to deploy (expanded deploy-dev/deploy-qa): --from deploy re-runs the failed iteration as documented.

Likely cause

computeStepsToReset() in src/domain/workflows/execution_service.ts matches persisted forEach expansions with name.startsWith(tmpl + "-"). For tmpl = "deploy-${{ self.env }}" the prefix deploy-${{ self.env }}- never matches deploy-qa. No test covers templated names.

Suggested fix

Match expansions through the run record's forEachTemplate (already emitted in step_skipped/step events) rather than by name prefix, or store the template name on each expanded StepRun when replaceExpandedSteps() runs. Emit an error when --from resolves to zero persisted steps instead of silently proceeding.

Environment

swamp 20260822.011157.0-sha.06b61472, Linux x86_64.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

8/22/2026, 7:19:35 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.