[AAASM-2328] 🐛 (ci): Retry gh release download on cross-repo race (release not found)

[Chisanan232]

Description

release-node.yml fires on the same tag-push event as agent-assembly's Release workflow, in parallel. agent-assembly takes ~10 min to build + publish the binaries release-node depends on, so the first download attempt consistently fails:

gh release download "v0.0.1-alpha.3" --repo AI-agent-assembly/agent-assembly --pattern "aasm-*.tar.gz" --dir bin-staging
release not found

Observed on alpha-2 and alpha-3 dry-runs. Hidden in alpha-1 by an earlier-failing pnpm-lock step (AAASM-2098).

Fix

Wrap gh release download in a retry loop: up to 20 attempts × 60s = 20 min ceiling. Distinguish 'release not found' (race → retry) from other errors (auth, rate-limit → fail-fast).

Alternatives considered

Option	Why not
workflow_run cross-repo trigger	Only fires for same-repo workflows; not feasible cross-repo
repository_dispatch from agent-assembly	Cleaner architecturally but needs PAT + extra wiring. Defer until polling cost is a real issue.
Manual workflow_dispatch only	Loses automation entirely

Retry-with-backoff is the smallest change that solves the race.

Local verification

• Simulated retry on race: 3-attempt loop with first 2 returning 'release not found' → third succeeds → loop exits cleanly
• Fail-fast on non-race error: HTTP 403 rate limit → grep miss on 'release not found' → exit 1 without retry

Related

• Jira: AAASM-2328
• Parent: AAASM-1203

— Claude Code (Opus 4.7, 1M context)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Chisanan232]

Claude Code review — AAASM-2328

CI state

25/25 SUCCESS — mergeable=MERGEABLE, mergeStateStatus=CLEAN. Full node-sdk matrix green. Note: the retry loop itself only fires on tag-push (when release-node actually runs), not on PR — so PR CI doesn't directly exercise the retry behavior. Verification is local simulation + the next alpha-tag-push.

Scope vs. acceptance criteria

AC	Verified	Status
gh release download wrapped in 20×60s retry loop (~20 min ceiling)	confirmed	✅
Distinguishes 'release not found' (race → retry) from other errors (auth, rate-limit → fail-fast)	grep-based discrimination confirmed locally	✅
Clear error message at retry-exhaustion: "Release v${RELEASE_TAG} never appeared after $((MAX_ATTEMPTS * 60))s — agent-assembly Release pipeline likely failed"	confirmed	✅
actionlint clean	yes	✅
set -euo pipefail semantics preserved (the if cmd; then construct correctly suspends set -e for the conditional)	verified by inspection	✅

Design choices worth recording

Why retry-with-backoff over alternatives

• workflow_run cross-repo: Not feasible — only fires for same-repo workflows.
• repository_dispatch from agent-assembly: Cleaner architecturally but needs PAT + cross-repo wiring; defer until polling cost becomes a real issue.
• Drop push: tags trigger, manual workflow_dispatch only: Loses automation entirely.

Retry-with-backoff is the smallest change that solves the actual problem. If 20 min polling per release becomes meaningful CI-minutes cost (~$0.04 at ubuntu-latest rates), revisit repository_dispatch.

Why 20 attempts × 60s

agent-assembly's Release pipeline observed durations:

• alpha-1: ~12 min total (build × 4 then publish)
• alpha-2: ~11 min
• alpha-3: ~10 min

20 min ceiling gives ~2× headroom for outliers. Could tighten to 15 if observed durations stay stable.

Subtle correctness detail

The if gh release download ... 2>&1 | tee /tmp/gh-rd.log; then form does two things:

1. Captures both stdout and stderr to the log file (via 2>&1 | tee)
2. Uses the exit code of the LAST command in the pipe (tee, not gh) — but tee only fails on file-write errors, so it almost always returns 0

The exit code we actually want is gh release download's. The pipe-to-tee masks that. However, the if then-branch correctly handles the success path (regardless of tee's exit), and the else-branch path is reached via the grep on the log file — which is the actual signal we want. So the logic is correct, but the pipe construct is more brittle than a gh release download ... > /tmp/gh-rd.log 2>&1 would be.

Not blocking — the current form works correctly under the observed failure modes. But a small follow-up to use pipefail-aware redirection would be cleaner.

Verdict

Ready for human approval and merge. The fix is correct, locally verified, design choices documented. The pipe-construct quibble in the section above is style, not correctness.

— Claude Code (Opus 4.7, 1M context)