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

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:

Not specified by the original author.

TL;DR: Stop waiting on CI with one long blocking call. Poll the combined status of the head commit on a bounded schedule (short interval, hard max wait), and when the max wait expires, post the review anyway with a note that checks are still pending - or park a draft and retry later. Bounded polling plus a fallback action means the review always lands instead of dying in a timeout.

code review agent timed out waiting for CI status checks before posting review

1. Fetch the combined status for the PR's head commit once, with a short request timeout. Record which checks are pending, which passed, and which failed. Expected: a list like "3 passed, 1 failed, 2 pending" instead of an open-ended wait.

2. Replace any single long wait with bounded polling: check status every 30 seconds, up to a hard cap of about 10 minutes. Expected: the loop exits on its own at the cap even if checks never finish.

3. Decide the on-timeout policy up front and encode it. Option A: post the review with a visible "CI still pending at review time" note. Option B: save the review as a draft, mark the PR as "review drafted, checks pending", and let a follow-up run submit it when checks complete. Expected: no code path ends in an unhandled timeout; the review is either posted or safely parked.

4. Record the outcome in the agent's per-PR state: review posted or draft parked, plus which checks were still pending. Expected: a follow-up run can pick up exactly where the timed-out run stopped.

5. If you chose the draft policy, add a lightweight recheck job that wakes when the pending checks finish and submits the parked review. Expected: the review goes out within minutes of CI completing, without a human nudge.

6. Re-run against a PR with a slow check suite and watch the timeline. Expected: the review posts (or parks) at the bounded wait limit, never hanging past it.

Use this when

• The review run stalls while checks are pending and eventually times out
• The agent log shows repeated status polls with no exit condition
• Reviews arrive hours late because one slow check held up the whole run
• You want reviews posted even when CI is still running

Not for this skill when

• Checks are failing, not pending (that is a code problem, not a waiting problem)
• The timeout is on fetching the diff or posting comments, not on check status
• A required status check never reports at all because the workflow is misconfigured (fix the workflow, see the actionlint/yamllint skills)
• The agent is rate limited on the status API rather than waiting on check results

Variant phrasings

• "review agent waits forever for checks to finish"
• "agent blocked on pending status checks before review"
• "CI checks pending, review never posted"
• "how long should a review bot wait for CI"

Why it happens

Review agents are usually written as a straight-line script: fetch diff, wait for CI, analyze, post. The "wait for CI" step has no deadline because the author assumed checks finish in minutes. On a busy repo a queued workflow or a flaky required check can sit pending for an hour, and the single blocking wait eats the whole run budget. Bounded polling with a fallback turns an assumption into a contract.

Edge cases

• A check that is "pending" because its workflow file has a syntax error will never complete. Cap the wait, then flag the broken workflow instead of parking the review forever.
• Posting a review while required checks are still pending can confuse branch protection messaging. The pending note in the review body keeps humans oriented.
• If the repo requires checks to pass before merge, a review posted early is advisory only. Say so in the review so nobody treats it as a merge signal.
• Draft parking needs a durable store. A draft kept only in the timed-out run's memory is lost when the run dies.

Provenance

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

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

Thread query: code review agent timed out waiting for CI status checks before posting review

TL;DR:

Not specified by the original author.

TL;DR: Scrolling a virtualized files list fires a request per viewport, so fast blind scrolling outruns the page and Playwright's default timeout gives up. Slow down: scroll one viewport at a time, wait for the row count to settle after each scroll, raise timeouts only for the scroll step, and stop scrolling once a full pass adds no new rows. If scrolling still will not finish, take the file list from the paginated files API instead.

playwright timeout on GitHub's PR files page while the review agent scrolled

1. Confirm where the timeout hits. Check whether it fires on the initial page load, on a scroll action, or on a wait after scrolling. Expected: you know which step needs the fix instead of raising every timeout blindly.

2. Wait for network calm before the first scroll. Use a wait for network idle (or for the first file row) with an explicit timeout before scrolling starts. Expected: scrolling begins from a hydrated list, not an empty container.

3. Scroll incrementally. Move the list container one viewport at a time, then wait briefly for new rows to mount before the next scroll. Expected: each scroll's data fetch completes before the next one starts, so requests stop piling up.

4. Stop on stabilization. After each pass, count collected rows; when a full scroll pass adds no new rows, stop - do not scroll a fixed number of times. Expected: scrolling terminates on its own, even on lists that keep growing slowly.

5. Scope the timeout raise narrowly. Increase the timeout only for the scroll-and-settle step, not globally, so real hangs elsewhere still fail fast. Expected: the scroll step gets room while the rest of the run keeps tight timeouts.

6. Add the API escape hatch. If scrolling still times out, abandon the browser for the file list, fetch the paginated files API, and log the fallback. Expected: the run completes with a full file list even when the page will not scroll cleanly.

Use this when

• Playwright times out while scrolling the PR files page
• Scroll passes never finish on large files lists
• The scraper stalls partway through row hydration
• You need reliable row collection from a virtualized list

Not for this skill when

• The timeout is on initial page load with no scrolling involved (page-load hang, different fix)
• The scrape returns empty without any timeout (selector/virtualization problem)
• GitHub serves a rate-limit interstitial (rate-limit problem, not a scroll problem)
• You only need the file list (use the files API directly and skip the browser)

Variant phrasings

• "playwright scroll timeout on GitHub files changed"
• "browser automation stalls scrolling PR file list"
• "virtualized list scroll keeps timing out"
• "increase timeout for scrolling files page"

Why it happens

Each scroll increment triggers async fetches for the newly visible rows. Scrolling faster than the page can fetch means pending requests queue up, the DOM never settles, and Playwright's action timeout expires while the page is still legitimately working. It looks like a hang, but it is usually just an overloaded page.

Edge cases

• Network-idle waits can themselves time out on pages with polling or analytics. Prefer waiting for the row-count to stabilize over strict network idle.
• Very large PRs (thousands of files) may never scroll cleanly in a reasonable time. Set a scroll budget (time or passes) and fall back to the API when it is spent.
• Headless browsers scroll and render slower. Tune the per-scroll pause for the CI environment, not your dev machine.
• Rows can re-mount during scrolling, so dedupe collected rows by file path before counting stabilization.

Provenance

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

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

Thread query: playwright timeout on GitHub's PR files page while the review agent scrolled

TL;DR: