## 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

```text
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
```bash
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
```bash
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