What version are you using?
stellar/binaries as currently published on main.
What did you do?
Used the action to install prebuilt cargo tools in CI — for example uses: stellar/binaries@v45 with name: cargo-hack and version: 0.5.28 — including in several jobs that gate stellar/rs-soroban-sdk's GitHub merge queue (semver-checks, build, test, build-fuzz, expand-test-wasms). Each invocation downloads the release tarball from GitHub Releases with the single curl command above.
What did you expect to see?
A transient network blip while fetching the release asset — for example a 503 from GitHub Releases or objects.githubusercontent.com — should be retried so it does not fail the build, the same way the rest of the pipeline already rides out transient 5xx (cargo via CARGO_NET_RETRY, and actions/checkout and actions/upload-artifact / download-artifact via their built-in retries).
What did you see instead?
Because the download is a single curl -fL ... | tar xvz with no retry, a transient 503 fails curl, which fails the step and the whole job even though nothing is wrong with the caller's build. In merge-queue builds this fails a required check, and GitHub immediately evicts the pull request from the merge queue; re-queuing a batch of PRs afterward takes real effort, so an arbitrary HTTP blip during a tool download repeatedly knocks PRs out of the queue for reasons unrelated to the change under test.
Suggested fix: give curl its own retry, and download to a file before extracting so a mid-stream failure can be retried cleanly (piping curl | tar can't recover a partially-consumed stream). In the final step of action.yml:
# before
curl -fL https://github.com/stellar/binaries/releases/download/$ref/$file | tar xvz -C $INSTALL_PATH
# after
url="https://github.com/stellar/binaries/releases/download/$ref/$file"
curl --retry 5 --retry-all-errors --retry-delay 2 -fL -o "$RUNNER_TEMP/$file" "$url"
tar xvz -C "$INSTALL_PATH" -f "$RUNNER_TEMP/$file"
--retry handles transient failures and --retry-all-errors ensures HTTP 5xx responses are retried too (which --retry alone treats inconsistently across curl versions). If you'd rather keep the one-liner, curl --retry 5 --retry-all-errors --retry-delay 2 -fL <url> | tar xvz -C $INSTALL_PATH is a smaller change that still retries the request, just without the clean mid-stream recovery the temp-file form gives. Either way it stays tiny and relies on curl's built-in retry rather than any custom retry logic.
What version are you using?
stellar/binaries as currently published on
main.What did you do?
Used the action to install prebuilt cargo tools in CI — for example
uses: stellar/binaries@v45withname: cargo-hackandversion: 0.5.28— including in several jobs that gate stellar/rs-soroban-sdk's GitHub merge queue (semver-checks, build, test, build-fuzz, expand-test-wasms). Each invocation downloads the release tarball from GitHub Releases with the singlecurlcommand above.What did you expect to see?
A transient network blip while fetching the release asset — for example a 503 from GitHub Releases or objects.githubusercontent.com — should be retried so it does not fail the build, the same way the rest of the pipeline already rides out transient 5xx (cargo via CARGO_NET_RETRY, and actions/checkout and actions/upload-artifact / download-artifact via their built-in retries).
What did you see instead?
Because the download is a single
curl -fL ... | tar xvzwith no retry, a transient 503 fails curl, which fails the step and the whole job even though nothing is wrong with the caller's build. In merge-queue builds this fails a required check, and GitHub immediately evicts the pull request from the merge queue; re-queuing a batch of PRs afterward takes real effort, so an arbitrary HTTP blip during a tool download repeatedly knocks PRs out of the queue for reasons unrelated to the change under test.Suggested fix: give curl its own retry, and download to a file before extracting so a mid-stream failure can be retried cleanly (piping
curl | tarcan't recover a partially-consumed stream). In the final step ofaction.yml:--retryhandles transient failures and--retry-all-errorsensures HTTP 5xx responses are retried too (which--retryalone treats inconsistently across curl versions). If you'd rather keep the one-liner,curl --retry 5 --retry-all-errors --retry-delay 2 -fL <url> | tar xvz -C $INSTALL_PATHis a smaller change that still retries the request, just without the clean mid-stream recovery the temp-file form gives. Either way it stays tiny and relies on curl's built-in retry rather than any custom retry logic.