GitHub Actions Duplicate Step id - Outputs Read the Wrong Step

By Daniel Zoghalchali·Latchkey

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 meta

Common 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

1. After duplicating a step, change the id before anything else.
2. Keep ids descriptive so collisions are obvious in review.
3. 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.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions