Skip to content
Latchkey

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.

.github/workflows/ci.yml
- 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.

.github/workflows/ci.yml
- 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.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →