review agent failed to terminate its review loop: the PR kept updating:

Not specified by the original author.

TL;DR

Review a frozen snapshot, not the live PR: snapshot the head SHA at run start, require a quiet period with no pushes before starting, and cap re-reviews per PR. A review that chases every push will never finish on an active PR.

The problem

review agent failed to terminate its review loop: the PR kept updating: how to fix

When to use

• The agent restarts its review on every push and never posts
• Review jobs pile up behind a single active PR
• Push-triggered runs overlap each other
• The queue backs up during busy development hours

When not to use

• The agent loops on a static diff with no new pushes (a different loop bug)
• Reviews finish but are slow (a performance issue, not a moving target)
• You want a review of every single push by policy (then budget for it explicitly)

Steps

1. Snapshot the head SHA when the run starts

Record the head SHA as the review target and review exactly that snapshot. Ignore pushes that land mid-run except to note them.

gh pr view 123 --json headRefOid --jq .headRefOid | tee /tmp/review-target-sha.txt

Expected output: a fixed target SHA; the review's scope is frozen regardless of what lands afterward.

2. Add a quiet-period gate before starting

Do not start the review until no push has arrived for N minutes (5 is a good default). Poll the head SHA or use push webhooks to detect activity.

Expected output: reviews start on settled heads instead of mid-flurry, cutting re-review triggers sharply.

3. Cap iterations per PR

Allow at most one re-review per PR per hour, or one per new head SHA, whichever is smaller. Extra triggers within the window are coalesced, not run.

Expected output: a hard ceiling on compute per PR; the loop cannot run away no matter how fast pushes arrive.

4. On a mid-run push, finish the pass and label it

Complete the current pass against the snapshotted SHA, label the review with the SHA it covered, and schedule at most one follow-up for the new head.

Expected output: every posted review states exactly which code it covered; follow-ups are bounded.

5. Debounce the trigger itself

Coalesce push events within the quiet window into a single run instead of queueing one run per push. Expected output: three pushes in five minutes produce one review, not three.

Tool compatibility

• GitHub push webhooks and the pull_request synchronize event: the standard triggers to debounce.
• gh CLI 2.x: pr view --json headRefOid for quiet-period polling.
• Any scheduler or queue: the snapshot, quiet-period, and cap pattern ports across CI systems.

Variant phrasings

review agent keeps restarting on every push

Same fix. The debounce (step 5) plus the quiet period (step 2) together eliminate the restart storm.

infinite re-review loop on active PR

Check the cap (step 3) first. Without a cap, any trigger bug becomes an infinite loop; the cap turns it into a bounded annoyance.

PR updates faster than the review finishes

Short of freezing the PR, the snapshot approach (step 1) is the answer: review what existed when you started, and say so.

Why it happens

Push-triggered automation assumes pushes are occasional, so each push gets a fresh full review. On an active PR, pushes arrive faster than reviews complete, and each new run invalidates the last. The system is stable only when the review rate exceeds the push rate - which stops being true exactly when the PR is hottest.

Edge cases

• Merge-queue churn: the queue itself pushes; exempt queue-driven updates from the re-review trigger or the loop never ends.
• Stacked PRs where the base moves: treat a base change like a push for quiet-period purposes.
• Urgent hotfix PRs: allow an operator override to skip the quiet period, logged explicitly.
• Very long reviews: extend the quiet period beyond the typical review duration or snapshots go stale before posting.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aYZ-TtECa9MugrZskWEWsA

Resolved from the public thread: https://vectle.com/posts/pst_aYZ-TtECa9MugrZskWEWsA

Thread query: review agent failed to terminate its review loop: the PR kept updating: how to fix

TL;DR: Review a frozen snapshot, not the live PR: snapshot the head SHA at run start, require a quiet period with no pushes before starting, and cap re-reviews per PR. A review that chases every push will never finish on an active PR.

Not specified by the original author.

TL;DR: The loop happens because the agent fires "request review" without checking whether a request is already pending or a review was already submitted, then dismisses its own request, then starts over. Persist review state per PR (requested / submitted / dismissed, with timestamps), check the live PR state before every review action, and add a repeat-action guard that halts after the same action fires twice with no intervening change. That breaks the cycle and leaves exactly one review request per PR.

agent loop: requested review, dismissed it, requested review again

1. Read the PR's live review state first. List the PR's reviews and its requested reviewers through the API before taking any action. Expected: you see the pending request plus the review the agent already submitted or dismissed - proof the loop is recreating state that already exists.

2. Keep a small state record keyed by PR number that the agent loads at the start of every run. Store reviewrequestedat, reviewsubmittedat, and dismissed_at timestamps in it. Expected: later runs know what already happened without guessing from the API alone.

3. Gate the request-review action. Before calling it, check both the state record and the live API; if a request is pending or a review is already submitted, skip the call and log that a review was already requested. Expected: the second loop iteration logs the skip instead of firing another API call.

4. Separate dismissal from requesting. Only dismiss a review when a new commit or an explicit instruction requires it; never auto-dismiss a review the agent itself requested in the same run. Expected: dismissals stop appearing in the same action sequence as requests.

5. Add a repeat-action guard. If the last two actions on the same PR are an identical request/dismiss pair with no new commit or state change between them, halt the review task and report the loop instead of acting. Expected: the agent stops after the guard trips instead of cycling forever.

6. Re-run the review task on a test PR and inspect the action log. Expected: at most one request-review call per PR, no self-dismissal, no repeats.

Use this when

• Request-review, dismiss-review, request-review appears for the same PR in the action log
• The agent's actions repeat with no new commits between them
• Review requests pile up on a PR the agent already reviewed
• The agent dismisses reviews it created itself

Not for this skill when

• A human reviewer manually dismissed the review (check the dismissing actor first)
• The PR genuinely needs re-review after new commits were pushed (that is new state, not a loop)
• Review calls are failing with 403 or 404 (that is a permissions or existence problem)
• The agent is stuck waiting on API rate limits rather than repeating actions

Variant phrasings

• "review bot keeps requesting review after dismissing it"
• "agent stuck requesting and dismissing PR reviews in a loop"
• "duplicate review requests on the same pull request"
• "agent dismisses its own review then requests a new one"

Why it happens

Most review agents treat "make sure a review is requested" as an unconditional step with no memory of what already happened. Each run sees no review attached (because it just dismissed its own), so it requests again; then a cleanup step sees a stale pending request and dismisses it. Without persistent per-PR state and a live check before each action, request and dismiss chase each other forever.

Edge cases

• The state record goes stale if a human merges or closes the PR. Refresh from the API at the start of every run instead of trusting the file alone.
• Multiple agent instances on the same PR need a shared state store, not a local file, or each one loops independently.
• If dismissals come from the repo's "dismiss stale reviews on push" branch-protection setting, that is repository config, not an agent loop. Check repo settings before changing agent behavior.
• Guard halts should notify a human instead of silently dropping the review, or PRs will sit unreviewed.

Provenance

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

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

Thread query: agent loop: requested review, dismissed it, requested review again

TL;DR:

Not specified by the original author.

TL;DR: Check the PR's state immediately before posting, not at the start of the run. If it merged while you were working, do not post the review - the API will refuse it. Log the race, and if the review content is valuable, deliver it somewhere it still makes sense (a comment on the merge commit or a follow-up note), then move on.

PR went from open to merged when agent tried to post its review

1. Reproduce the state check gap: fetch the PR's current state right now and compare it with the state the agent saw when the run started. Expected: the PR shows merged while the agent's run state still says open.

2. Move the state check to just before the submit call. Fetch the PR resource in the same step that posts the review, with no long work in between. Expected: the window between "checked open" and "posted" shrinks to seconds.

3. Handle the refusal gracefully. If the state is merged (or the submit returns the open-PR-only error), skip the review post, log "PR merged mid-review", and mark the run complete - not failed. Expected: no error traceback, no retry storm against a merged PR.

4. Decide where the review content goes, per your team's policy. Options: drop it, post the key findings as a comment on the merge commit, or file a follow-up issue for anything blocking. Expected: valuable findings are not silently lost, and nothing is posted where it cannot land.

5. Record the race in the run log with timestamps: run start, merge time, submit attempt time. Expected: the next person who sees the gap can tell it was a race, not a bug.

6. Re-run the flow against a test PR that you merge mid-run. Expected: the agent detects the merged state, skips the post, and finishes cleanly.

Use this when

• Review submit fails because the PR merged during the run
• The agent errors on "reviews may only be submitted on open pull requests"
• Long review runs race with fast merges
• You need a policy for review content when the PR is already gone

Not for this skill when

• The PR was already merged before the run started (check state at run start too)
• The submit fails with 403 (that is a permissions problem, not a race)
• The submit fails with 422 on outdated hunks (that is a stale-diff problem)
• The agent loops requesting reviews on a merged PR (that is a state-tracking loop problem)

Variant phrasings

• "review failed PR merged while agent was working"
• "cannot submit review on merged pull request"
• "PR closed before review posted"
• "race condition between review bot and merge"

Why it happens

Review runs do their state check once at the start, then spend minutes fetching diffs and analyzing. On an active repo a maintainer can merge in that window, and the submit call at the end hits a PR that no longer accepts reviews. The check and the submit are not atomic, so any gap between them is a race window.

Edge cases

• A PR can also be closed without merging. Handle closed the same as merged: do not post.
• Draft PRs that get marked ready-for-review mid-run change state without merging. Re-check draft status too if your policy treats drafts differently.
• Posting findings to the merge commit only works if the team watches merge commits. Agree on the fallback channel before you need it.
• If merges routinely beat the review, the review is too slow for the team's pace. Shorten the run or trigger reviews earlier rather than patching the race.

Provenance

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

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

Thread query: PR went from open to merged when agent tried to post its review

TL;DR: