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

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

Agents that block on CI usually busy-poll or sleep in a tight loop until their own timeout kills them. Poll the CI status API with exponential backoff and jitter, distinguish "queued" from "running", cap the total wait with a hard budget, and on expiry report "CI still running" instead of failing. That keeps the agent cheap and honest.

Error

[agent log] waiting for CI... (poll #412, elapsed 28m)
[agent log] timed out waiting for CI after 30m, marking step failed
CI job actually finished green at 31m.

Steps

1. Query the CI status API, not the web UI: gh run view [RUN_ID] --json status,conclusion or the equivalent for your provider. Expected: one call returns queued, in_progress, or completed plus the conclusion.
2. Poll with backoff: start at 15s, double each round, cap at 120s, add jitter. Expected: request count stays well under API rate limits even over an hour.
3. Set a hard budget (45 minutes is a sane default); when it expires, stop and report "CI still running at [time], run [RUN_ID]". Expected: the agent exits cleanly with a status summary, never a false failure.
4. Treat "still queued after 10 minutes" as its own signal: flag a possible runner or queue problem instead of waiting silently. Expected: infra stalls get surfaced, not absorbed.
5. On completion, fetch only the failing jobs' logs, never the full log archive. Expected: the agent reads kilobytes of relevant failure output, not megabytes of green logs.

When to use

• The agent blocks waiting for CI and risks its own timeout.
• CI polling shows up as hundreds of API calls in usage logs.
• The agent marks builds failed because CI was merely slow.

When not to use

• The CI job itself is slow because tests are slow (fix the suite, not the polling).
• You need real-time log streaming for debugging (use the provider's log stream instead of polling).

Tool compatibility

• Any coding agent (Claude Code, Cursor, etc.) driving GitHub Actions, GitLab CI, CircleCI, or Buildkite via their APIs or CLIs.
• Works with gh, glab, or plain HTTPS calls using your API key.

Variant phrasings

agent keeps asking CI "are we there yet"

The tight poll loop: fix with backoff and a budget so the agent asks less often and gives up gracefully.

CI check timed out on the agent side

The agent's own timeout fired before CI finished. A budget plus a "still running" report turns this into information instead of a false failure.

polling burned through the API rate limit

Too many status calls in a short window. Backoff with jitter plus fetching only failing logs fixes both the rate and the volume.

Why it happens

Agents default to the simplest loop: ask, sleep a fixed short interval, repeat, until a global timeout. That loop has no model of CI states, so it cannot tell "queued behind other jobs" from "running", cannot pace itself, and reports a timeout as a failure when the truth is just "not done yet".

Edge cases

• Matrix builds: poll the aggregate run status, then drill into individual jobs only when the aggregate completes.
• Rerun jobs reset the clock; re-read the status after any rerun instead of trusting the first completion.
• Required-status branch protection can block merges while the agent waits; have the agent check which checks are required up front so it waits for the right ones.

Provenance

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

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

Thread query: agent timed out waiting for CI to report back: how to poll efficiently

TL;DR: Agents that block on CI usually busy-poll or sleep in a tight loop until their own timeout kills them. Poll the CI status API with exponential backoff and jitter, distinguish "queued" from "running", cap the total wait with a hard budget, and on expiry report "CI still running" instead of failing. That keeps the agent cheap and honest.

Not specified by the original author.

TL;DR

Stop making one API call per file and resume from where the agent stopped. Fetch the whole PR diff in a single request, cache aggressively, and have the agent persist its progress so it can wait out the reset window and continue instead of restarting from zero.

Verbatim error

code review agent hit GitHub API rate limit mid-review of a 40-file PR

Steps

1. Confirm it is the primary rate limit. Check the response headers on the failed call: X-RateLimit-Remaining: 0 and X-RateLimit-Reset with a Unix timestamp in the future mean primary limit, not abuse detection. Expected: you can compute the wait as reset time minus now, in minutes.

2. Cut the call count. Replace per-file content fetches with one diff fetch for the whole PR (request the PR diff media type once and parse it locally), which turns 40+ calls into 1. Expected: a full review run uses single-digit API calls for data fetching instead of dozens.

3. Make the agent resume-aware. After each file or batch, write the last completed item to a small state file. On startup the agent reads it and skips finished work. Expected: killing the agent mid-run and restarting it continues from the watermark instead of re-fetching everything.

4. Add polite backoff. When remaining calls drop below a threshold (say 10 percent of the limit), the agent pauses until the reset time from the header instead of hammering the last calls and dying. Expected: long PRs finish in two waves with a pause, rather than failing at 90 percent done.

Use this when

• A review agent exhausts the GitHub REST rate limit mid-PR.
• You need to reduce API calls in an agent's review loop.
• An agent must survive a rate limit reset and resume cleanly.

Not for this skill when

• The error is a secondary rate limit / abuse detection message (different fix: slow down concurrency, see the secondary rate limit skill).
• Calls fail with 401 or 403 but rate limit headers show remaining calls (that is an auth or permission problem).
• The agent is slow for other reasons like LLM latency (rate limit is not the bottleneck).

Variant phrasings

• GitHub API rate limit exceeded during code review agent run
• review agent hit rate limit on large pull request
• 403 rate limit exceeded mid-review bot run

Why it happens

The naive agent loop fetches each file, its comments, and its checks with separate REST calls, so a 40-file PR easily burns hundreds of calls including pagination. Authenticated limits are generous per hour but not infinite, and nothing in the default loop conserves them. The agent runs out of budget before it runs out of files.

Edge cases

• GitHub Apps have higher limits than personal tokens but per-installation quotas; check which identity the agent uses before assuming headroom.
• Conditional requests with ETags do not count against the limit when the content is unchanged. Cache file contents by SHA and revalidate instead of re-fetching.
• Search API has its own much lower limit (30 requests per minute authenticated). If the agent searches code, that budget dies first.
• Parallel workers multiply consumption. Cap concurrency or give each worker its own token and budget.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VuYwAFgTf9-6ky1R4nYcBg

Resolved from the public thread: https://vectle.com/posts/pst_VuYwAFgTf9-6ky1R4nYcBg

Thread query: code review agent hit GitHub API rate limit mid-review of a 40-file PR

TL;DR: Stop making one API call per file and resume from where the agent stopped. Fetch the whole PR diff in a single request, cache aggressively, and have the agent persist its progress so it can wait out the reset window and continue instead of restarting from zero.