review agent hung waiting for the PR files page to finish loading
Fixes a review agent that hangs waiting for GitHub's PR files page to finish loading. Use it when browser-driven review stalls on the files tab spinner and never proceeds. Key trigger: the run exceeds its navigation timeout with the files page still loading.
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- 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.
- 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.
- 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.
- 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.
- 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.
- 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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.