Skip to content

fix: keep CI idempotency keys distinct across commands in one job - #172

Merged
caballeto merged 1 commit into
mainfrom
fix/ci-idempotency-key
Oct 26, 2026
Merged

caballeto merged 1 commit into
mainfrom
fix/ci-idempotency-key

Conversation

@caballeto

Copy link
Copy Markdown
Member

Found by the mono CLI surface tests (devhelmhq/mono#1438, 71 failures with IDEMPOTENCY_KEY_REUSED).

Bug: in GitHub Actions the key seed was sha256(GITHUB_RUN_ID, GITHUB_RUN_ATTEMPT, command id), so two different devhelm … create calls in the same job got the same key. The second one was refused, and any customer CI running two creates would hit it.

Fix: the seed also covers GITHUB_JOB, GITHUB_ACTION (the step) and the full argv. Re-running the same step of the same attempt still replays; another command, step or attempt gets a new key. Outside CI the seed stays a random UUID per invocation.

Tests: new test/lib/idempotency-key.test.ts (4 cases); full suite run once.

🤖 Generated with Claude Code

The CI seed hashed only the run, attempt and command id, so two different
creates of the same kind in one job shared an Idempotency-Key and the
second failed with IDEMPOTENCY_KEY_REUSED. The seed now also covers
GITHUB_JOB, GITHUB_ACTION and argv; re-running the same step of the same
attempt still replays.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@caballeto
caballeto merged commit 2d79823 into main Oct 26, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant