Repository navigation
fix(ci): retry the CI Required results download after a pause - #3298
Conversation
GitHub sometimes refuses artifact downloads for a few minutes ("Egress is
over the account limit"). actions/download-artifact gives up after about
25 s, so CI Required reported every lane it could not fetch as
missing-lane-output although all lanes had passed: run 39914661162 (#3281)
and main run 39931258427 (4e9f593) both needed a manual rerun of the
failed job.
Download twice more, after 60 s and then 120 s, before the aggregate step
runs; clear the partial download before each retry. The happy path is
unchanged: the retry steps run only when the previous download failed.
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
… last one Review follow-up: the manual rerun of main run 39931258427 passed 8 min after the failure, so wait 240 s instead of 120 s before the final attempt. Name the download and wait steps, log a notice before each retry, and drop the mode check from the retry conditions (a retry runs only after a download that the mode check already admitted failed).
|
Codex review: needs maintainer review before merge. What this changesThis PR retries failed CI result downloads after 60-second and 240-second pauses, clearing partial downloads before each retry. Example: GitHub temporarily refuses the CI Required artifact download.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open: it addresses confirmed CI artifact-download failures, preserves failure enforcement, and introduces no identified correctness defect. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherThe CI Required workflow job downloads lane-result artifacts and passes them to the existing aggregator, which verifies job success, result completeness, and source identity. flowchart TB
A[Completed CI lanes] --> B[Download result artifacts]
B -->|success| E[Aggregate and validate results]
B -->|failure| C[Wait 60 seconds and retry]
C -->|success| E
C -->|failure| D[Wait 240 seconds and retry]
D --> E
E --> F[CI Required conclusion]
Technical reviewBest possible solution: Keep the bounded retries in the existing CI Required job while preserving cancellation handling and strict aggregation. Do we have a high-confidence way to reproduce the issue? The current-main workflow immediately reaches strict aggregation after a failed download, and GitHub job records corroborate that failure sequence; transient GitHub throttling cannot be triggered deterministically from the supplied evidence. Is this the best way to solve the issue? Retrying the existing pinned action is a focused response to an external transient failure, and the final non-tolerated attempt prevents a persistent outage from becoming a passing check. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against a4146f549835. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 23, 2026, 7:25 AM ET / 11:25 UTC. |
…3304) Moves the results-download retry from #3298 (download, wait 60 s, retry, wait 240 s, retry) into a shared composite action, .github/actions/download-results. CI Required in ci.yml and the full-integration aggregate job both use it, so a temporary artifact egress refusal no longer fails the full integration aggregate on the first try.
Problem
GitHub sometimes refuses artifact downloads for a few minutes ("Egress is over the account limit").
actions/download-artifactgives up after its own retries, about 25 s, and the CI Required job then reports every lane it could not fetch asmissing-lane-output, even though every lane passed. Two sightings on 10-23 within about two hours:Each one needs a maintainer to rerun the job.
Change
In the CI Required job, the results download now continues on error. If it fails, the job waits 60 s, clears the partial download and tries again; if that also fails, it waits 240 s and tries a third time without
continue-on-error, so a lasting outage still fails the job as before. The aggregate step is unchanged. On the normal path the extra steps are skipped. The retry steps run only after a download that the mode check already admitted failed, so they check only the cancellation guard and the previous outcome.Every new step keeps the
!cancelled() && !contains(needs.*.result, 'cancelled')guard that the existing CI Required test requires.Verification
actionlint .github/workflows/ci.yml: clean.node scripts/ci/run-tests.mjs audit: no issues.node --test tests/integration/ci-impact.test.mjsat 2 CPUs: 66/66 pass.steps.<id>.outcome == 'failure'after acontinue-on-errorstep, which is documented Actions behaviour.Risks
Low. Workflow-only. A failed download now adds up to about 5 minutes of waiting before CI Required reports; each retry logs a notice. The last wait is 240 s because the manual rerun of the main run passed 8 minutes after its failure. Retries add a little more artifact egress while throttled.