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

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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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