GitHub Actions re-run: which idempotency key for Sume jobs?

Build the Idempotency-Key from GITHUB_RUN_ID, not from GITHUB_RUN_ATTEMPT: GitHub says the run id does not change on a re-run, so a re-run sends the same key and, with an identical payload, gets the original Sume job back rather than a second paid one.

Sume behavior is from the Generation admission and Jobs and results docs; the GitHub variable text was read 2026-09-30.

What do the two GitHub variables do?

GitHub describes GITHUB_RUN_ID as “a unique number for each workflow run within a repository” that “does not change if you re-run the workflow run.” GITHUB_RUN_ATTEMPT “begins at 1 for the workflow run's first attempt, and increments with each re-run.”

What does the step look like?

The key is read from a shell variable, so the script needs no expression syntax.

# SUME_API_KEY is provided to the job env from a repository secret
- name: Submit Sume job
  run: |
    curl -sS -X POST https://api.sume.com/v1/image-1.0/generate \
      -H "Authorization: Bearer $SUME_API_KEY" \
      -H "Content-Type: application/json" \
      -H "Idempotency-Key: release-$GITHUB_RUN_ID" \
      -d '{"prompt":"Release banner, flat colors","mode":"async"}'

What if the payload changes between attempts?

The same key with a different payload is a 409 idempotency_conflict. If a re-run builds its prompt from something that moves, such as a timestamp, freeze that input from the first attempt or use a new key on purpose.

What does a re-run of a failed job return?

The docs say a repeated key with the same payload returns the original job; they do not spell out the case where that job already failed. Test it on a small job before relying on it, and read the job status before deciding to resubmit.