[earakely-scale]

What and why

The first run by hand of the release workflow on main (run 39511020412) failed on both attempts in the same place: a base image's pull, 429 Too Many Requests from public.ecr.aws.

#2 ERROR: failed to copy: httpReadSeeker: failed open: unexpected status code
https://public.ecr.aws/v2/docker/library/python/manifests/sha256:c208…: 429 Too Many Requests

• Why: the ten build jobs (five images × two platforms) started together. Each pulled its base images anonymously, and ECR Public allows one anonymous pull a second. fail-fast then cancelled the rest.
• Why it matters beyond this run: with publishing on, a failed build also keeps the release off PyPI.

What changes

• infra_build.py retry COMMAND... runs the command, and again after 30, 60 and 120 seconds while what it printed says a registry rate-limited it: ECR Public's 429, or the toomanyrequests error GHCR and Docker Hub send. Any other failure fails at once.
• The workflow wraps docker build, docker push and imagetools create in it. The registry lookups behind exists and verify-record retry the same way.
• The build matrix runs four at a time (max-parallel: 4), so its burst of base-image pulls is smaller.

The script still uses only the standard library and the docker CLI.

How it was tested

• New unit tests cover a command that works first time, one rate-limited twice then working, one that gives up after the three waits, a failure of another kind (not retried), a rate-limited registry lookup, and the workflow wiring. The unit tier passed (8,799).
• retry passes a whole command line, flags included, through to the command.

The real check is the next run by hand on main.

🤖 Generated with Claude Code

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking improvement needed to show command output promptly.

Findings

1.  Progress messages arrive late ▶

Fix with agent prompt

### Issue 1
.github/scripts/infra_build.py:116
`_streamed` writes each line without flushing it. In the release workflow, Python's output goes to a pipe, so short messages stay buffered until enough output arrives or the helper exits. The retry warning can also remain hidden during the waits, making the job look stuck. Flush after forwarding each line and printing the warning, or run the helper with unbuffered output.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds bounded retries for registry rate limits during image builds, pushes, tagging, and lookups.

• Infra image publishing retries when registries apply rate limits.
• Image builds run no more than four jobs at once.

One non-blocking issue remains: forwarded output and retry warnings can stay buffered.

_{Reviews (1) · Last reviewed commit: "fix(release): try an infra image's build..." · Reviewed by Greptile}

[greptile-apps]

Progress messages arrive late

_streamed writes each line without flushing it. In the release workflow, Python's output goes to a pipe, so short messages stay buffered until enough output arrives or the helper exits. The retry warning can also remain hidden during the waits, making the job look stuck. Flush after forwarding each line and printing the warning, or run the helper with unbuffered output.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/scripts/infra_build.py
Line: 116

Comment:
**Progress messages arrive late**

`_streamed` writes each line without flushing it. In the release workflow, Python's output goes to a pipe, so short messages stay buffered until enough output arrives or the helper exits. The retry warning can also remain hidden during the waits, making the job look stuck. Flush after forwarding each line and printing the warning, or run the helper with unbuffered output.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[earakely-scale]

Valid: fixed in #273, since this one had merged. _streamed flushes after each line it forwards, and the retry warning is printed with flush=True.