GitHub Actions Duplicate Step id - Outputs Read the Wrong Step
Two steps share the same id, so a later reference to steps.<id>.outputs resolves to whichever step the engine bound last - usually not the one you meant - and the value is wrong or empty.
What this error means
A step output reads a stale or empty value, or a conditional keyed on steps.<id>.outcome behaves as if it points at a different step than intended.
- id: meta
run: echo "v=1.0" >> "$GITHUB_OUTPUT"
- id: meta # same id reused
run: echo "v=2.0" >> "$GITHUB_OUTPUT"
- run: echo "${{ steps.meta.outputs.v }}" # ambiguous which metaCommon causes
Same id on multiple steps
A step id must be unique within a job. Reusing it means references resolve ambiguously and you cannot reliably address either step.
Copy-paste without renaming the id
Duplicating a step block and forgetting to change its id is the most common cause - both steps run, but only one id binding survives for reference.
How to fix it
Give every step a unique id
Rename ids so each producing step is addressable on its own.
- id: meta_v1
run: echo "v=1.0" >> "$GITHUB_OUTPUT"
- id: meta_v2
run: echo "v=2.0" >> "$GITHUB_OUTPUT"
- run: echo "${{ steps.meta_v2.outputs.v }}"Audit ids when copying steps
- After duplicating a step, change the id before anything else.
- Keep ids descriptive so collisions are obvious in review.
- Run actionlint, which flags some duplicate-id and bad-reference cases.
How to prevent it
- Keep step ids unique and descriptive within each job.
- Rename the id immediately when copying a step block.
- Reference outputs by the specific step id you intend.