Poll a slow Copilot with backoff instead of escalating on a timeout - #450
Merged
Conversation
A throttled Copilot can post its re-review tens of minutes after the request, well beyond a short poll window. The Bounded Retry Workflow read a poll timeout as a genuinely missing review and escalated to the maintainer. Clarify that a timeout means the review is pending, not missing: report "review still pending", poll on a widening interval, and enter escalation only when the requestReviews mutation no-ops or errors, or after a genuinely long confirmed-accepted wait. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the GitHub Copilot Review Runbook to distinguish a slow Copilot re-review from a missing re-review, so operators do not escalate prematurely when Copilot is throttling.
Changes:
- Adds guidance to treat poll timeouts as "review still pending" and continue polling with backoff.
- Narrows escalation to cases where the
requestReviewsmutation no-ops/errors or after a genuinely long, confirmed-accepted wait.
Uh oh!
There was an error while loading. Please reload this page.
ptr727 added a commit
that referenced
this pull request
Jul 26, 2026
…449, #450) (#451) Promotes two develop PRs to main: - **#449** - Rule 4 in `gh-write-guard.py`: deny any agent git operation that would only land by bypassing an active branch rule (direct push to a PR-gated branch, force where history is protected, delete where deletion is blocked, and the explicit-bypass flags `gh pr merge --admin` / `git commit|push --no-verify`). Judged against the branch's live rules, so a code-style develop denies and a config-style develop allows with no hardcoded list. 71 self-test cases; 18 Copilot findings resolved across the review. - **#450** - Copilot Review Runbook: a slow/throttled Copilot review is *pending, not missing* - poll with backoff and report "still pending" rather than escalating on a timeout. Carried-file/spec changes, so downstream repos re-vendor `.github/copilot-instructions.md`; the guard lives under `host-setup/` (hub tooling). Docs/tooling only - no release. Deploy of the guard to `~/.claude/hooks/` is held until this promotion passes review; the idempotent host installer + per-machine refresh tracking (#365) follow separately. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds one paragraph to the GitHub Copilot Review Runbook's Bounded Retry Workflow.
Why
While driving #449 through 13 review rounds in an hour, Copilot throttled and posted its final re-review ~36 minutes after the request - beyond a 15-minute poll window. The poll timed out, and the Bounded Retry Workflow treated that as a genuinely missing review and escalated. It was not missing, only pending.
Change
Clarify that a slow review is pending, not missing: a poll timeout is evidence only that the review has not landed yet, so report
review still pending, poll on a widening interval, and enter escalation only when therequestReviewsmutation no-ops/errors or after a genuinely long confirmed-accepted wait - never on one fixed poll window elapsing.This complements the #444 head-coverage gate (which prevents concluding clean too early) by preventing the opposite error - concluding unresponsive/blocked too early.
Docs only - no release.