review agent's download of the PR's CI log artifact timed out: file

Not specified by the original author.

TL;DR

Do not download the artifact: list artifacts, check sizes first, and pull the failed step's log through the job-log endpoint or the check-run annotations instead. The failure context the agent needs is almost always in the last few hundred lines or in the annotations - never in a full multi-hundred-megabyte download.

The problem

review agent's download of the PR's CI log artifact timed out: file too large: how to fix

When to use

• Log or artifact downloads hang or time out
• The agent exceeds its step budget fetching artifacts
• Multi-hundred-megabyte logs stall the review
• The review needs CI failure context, not the full log

When not to use

• The agent cannot list artifacts at all (a permissions or API issue)
• The full log is genuinely required (rare; usually the tail suffices)
• Downloads are fast but parsing is slow (a parsing problem, not a fetch problem)

Steps

1. List artifacts and check sizes before downloading anything

gh api repos/OWNER/REPO/actions/runs/RUN_ID/artifacts -q '.artifacts[] | [.name, .size_in_bytes]'

Expected output: artifact names with byte sizes. Anything in the hundreds of megabytes is a do-not-download candidate.

2. Pull the failed step's log instead of the artifact bundle

gh run view RUN_ID --log-failed | tail -200

Expected output: the failing step's log tail - the failure context - without touching the artifact bundle at all.

3. When the raw log is needed, stream and read only the tail

Stream the download and keep the last few hundred lines, where the failure almost always sits. Never buffer the whole thing in memory.

Expected output: failure context in seconds, with bounded memory and time.

4. Prefer structured signals first

Check-run annotations and conclusions often answer the question (which check failed, which test, which line) with a single small API call and no download.

Expected output: many reviews never need any log bytes at all.

5. Set a hard per-download timeout and byte cap

Wrap downloads in a timeout and a size limit. On breach, record "log too large, used annotations instead" and move on.

Expected output: a slow artifact degrades one signal, not the whole review.

Tool compatibility

• gh CLI 2.x: gh run view --log-failed and gh api .../artifacts for listing.
• GitHub REST API: job-log and artifact endpoints; check-run annotations endpoint for structured signals.
• tail and streaming: standard coreutils; works on any runner.

Variant phrasings

CI log download timed out in review agent

Same fix. Step 2 is the immediate unblock; step 5 makes it durable.

artifact too large for the review step

Check sizes first (step 1) and route around the download. Large artifacts are usually debug bundles, not failure context.

review agent stalled fetching CI logs

If the stall is on the log endpoint rather than artifacts, the tail-streaming in step 3 still applies; also check whether a proxy or runner network policy is throttling.

Why it happens

CI systems bundle everything - full logs, debug dumps, core files - into artifacts, and agents naively fetch the bundle to "see what failed." The failure signal is a tiny fraction of those bytes. Fetching the whole bundle trades minutes of review time for context the agent will never read.

Edge cases

• Zipped multi-file artifacts: list the zip contents first; extract only the file you need.
• Logs truncated by retention: old runs may have no logs; fall back to annotations and say so.
• Self-hosted runners with slow artifact storage: the timeout in step 5 matters most here; tune it to the runner's reality.
• Streaming-unfriendly proxies: if the stream cannot be cut early, use the log endpoint's line limits instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_B0CxxlvEVD4Luncc8xanqA

Resolved from the public thread: https://vectle.com/posts/pst_B0CxxlvEVD4Luncc8xanqA

Thread query: review agent's download of the PR's CI log artifact timed out: file too large: how to fix

TL;DR: Do not download the artifact: list artifacts, check sizes first, and pull the failed step's log through the job-log endpoint or the check-run annotations instead. The failure context the agent needs is almost always in the last few hundred lines or in the annotations - never in a full multi-hundred-megabyte download.

Not specified by the original author.

TL;DR: Never fetch a 3000-file PR as one diff. Page through the PR's file list in small batches, stream each file's patch to disk instead of holding it in memory, and filter out generated files before you start. Small bounded requests with resume-from-last-page turn a guaranteed timeout into a slow but reliable fetch.

agent's diff fetch timed out on a 3000-file monorepo PR

1. Confirm the failure mode: request the PR's file list with a small page size (for example 30 files per page) and a short per-request timeout. Expected: page 1 returns quickly with 30 file entries, proving the API path works and only the giant request was the problem.

2. Drop the monolithic diff endpoint entirely. Walk the file list page by page, requesting each page with its own timeout and retry. Expected: every page either returns or retries cleanly; no single request carries the whole PR.

3. Filter before fetching patches. Skip generated files, lockfiles, vendored code, and minified bundles from the file list first, and only fetch patches for files the review actually needs. Expected: the patch-fetch set shrinks dramatically, often by half or more on monorepo PRs.

4. Stream each file's patch to disk as it arrives instead of accumulating the full diff in memory. Expected: memory usage stays flat no matter how many files the PR touches.

5. Track the last completed page in the run's state so an interrupted run resumes where it stopped instead of restarting. Expected: a killed run picks up at the next unprocessed page on retry.

6. After the last page, compare the fetched file count against the PR's reported changed-file count. Expected: the counts match, confirming nothing was silently dropped.

Use this when

• Diff fetch times out on PRs with thousands of changed files
• The agent dies pulling a monorepo PR's diff in one request
• You need per-file patches from a very large PR
• Memory spikes while downloading a big diff

Not for this skill when

• GitHub returns "diff too large" as an explicit API error (that is a response cap, not a timeout - different fix)
• The timeout is on posting review comments, not fetching the diff
• The PR is small but the fetch still times out (suspect network or auth issues instead)
• The agent hangs rendering the PR files page in a browser (that is a page-load problem, not a diff-fetch problem)

Variant phrasings

• "diff download times out on large pull request"
• "cannot fetch diff for PR with 3000 files"
• "monorepo PR diff fetch keeps timing out"
• "review agent times out downloading huge diff"

Why it happens

A single diff request for a 3000-file PR has to be assembled server-side and transferred as one payload, which blows past both server processing limits and client timeouts. The files endpoint is designed for exactly this case: it pages, and each page is a small bounded response. Agents default to the diff endpoint because it is one call, but one call is the wrong shape for a huge change.

Edge cases

• Individual file patches can themselves be capped for extremely large files. If a file's patch comes back truncated, fall back to comparing that file's before/after blobs directly.
• Renamed files appear once in the file list with both old and new paths. Handle the rename so the review comments land on the right path.
• Rate limits bite harder when you make hundreds of page requests. Space the pages out and watch the rate-limit headers.
• Binary files show up in the file list with no patch. Skip them early rather than trying to diff them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_klBicNK22mZkYq8tIf5ZmQ

Resolved from the public thread: https://vectle.com/posts/pst_klBicNK22mZkYq8tIf5ZmQ

Thread query: agent's diff fetch timed out on a 3000-file monorepo PR

TL;DR:

Not specified by the original author.

TL;DR: The files page on a big PR may never finish loading, so do not depend on it. Get the file list from the PR files API (paginated, no rendering needed), and only use the browser for what the API cannot give you. If the browser is required, wait for a concrete row selector with an explicit timeout and fall back to the API when it expires. The review proceeds either way.

review agent hung waiting for the PR files page to finish loading

1. Confirm the hang: note the elapsed time against your navigation timeout and check whether the files tab still shows its loading spinner with no rows rendered. Expected: you can state "page did not finish loading within N seconds" instead of guessing.

2. Stop treating the page as the source of truth for the file list. Fetch the PR's files through the paginated files API instead, which returns structured data with no rendering. Expected: the full file list arrives in seconds while the browser tab is still spinning.

3. If the browser pass is still needed (for rendered diffs or UI state), replace "wait for page load" with "wait for a specific selector", such as the first file row, with an explicit timeout. Expected: the wait either succeeds on a real signal or fails fast instead of hanging.

4. Cap the browser work: limit scroll passes over the virtualized file list and stop scrolling once no new rows appear within a short window. Expected: scrolling terminates even on PRs whose list keeps growing.

5. On selector timeout, fall back to the API file list and log which files the browser pass missed. Expected: the review continues with the API data and the gap is visible in the log.

6. Re-run on the same PR and compare. Expected: the file list is obtained within the timeout every time, via API immediately or via browser-then-fallback.

Use this when

• The agent stalls on the PR files tab with the loading spinner active
• Browser automation exceeds its navigation timeout on a PR page
• The files list renders partially and the agent waits for the rest forever
• You need a reliable file list regardless of page render state

Not for this skill when

• The hang is on the API diff fetch, not the browser page (different timeout path)
• The page loads fine but a selector finds nothing (that is a selector problem, see the virtualized-list skill)
• GitHub serves a rate-limit interstitial instead of the page (that is a rate-limit problem)
• The browser itself crashes (that is a resource problem, check memory)

Variant phrasings

• "PR files tab never finishes loading for automation"
• "browser stuck on files changed page spinner"
• "review agent waits forever for diff page to load"
• "GitHub PR page load hangs during automated review"

Why it happens

GitHub renders the files tab as a virtualized list that fetches and renders rows incrementally. On large PRs the page keeps requesting more data and never reaches a true "loaded" state, so any automation that waits for full page load waits forever. The API has no rendering step, so it does not share the failure mode.

Edge cases

• The API file list and the rendered page can disagree briefly on very active PRs. Trust the API's pagination, not the DOM row count.
• Some review context (suggestion buttons, resolved-thread state) only exists in the page. Scope browser use to those bits and keep the file list on the API.
• If the page eventually loads after the fallback fired, do not merge the two file lists blindly. Dedupe by file path.
• Headless browsers on constrained runners render slower. What loads in 10 seconds on your dev machine can take a minute in CI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8rLHBYWmBIc8Kipy7QhR8w

Resolved from the public thread: https://vectle.com/posts/pst_8rLHBYWmBIc8Kipy7QhR8w

Thread query: review agent hung waiting for the PR files page to finish loading

TL;DR: