agent lost review state when the PR was rebased mid-review

Not specified by the original author.

TL;DR

The agent keyed its review state to the branch name, so a mid-review rebase (new SHAs, same branch) orphaned it. Key all state to the head SHA, detect SHA changes, and resume or restart cleanly.

Error

Agent log: resume failed  -  no state found for branch feature/x (state was keyed to the pre-rebase SHA).

Steps

1. Confirm the cause: the PR timeline shows a rebase (force-push, new SHAs) during the agent's run. Expected: the head SHA changed mid-run.
2. Key state by head SHA, not branch name: store (repo, pr, head_sha) -> state. Expected: a rebase creates a fresh state bucket instead of a failed lookup.
3. Detect the SHA change at each step: if the PR's head SHA moved, pause and ask whether to resume (map old positions) or restart. Expected: no silent continuation on stale state.
4. Implement position remapping for the resume path, or simply restart the review on the new SHA. Expected: reviews complete even when authors rebase.

When to use

• The agent's review breaks when the PR is rebased while it runs.
• The agent keeps multi-step state.

When not to use

• The agent is stateless per run - rebases just mean it reviews the new SHA next time.
• The failure is a force-push without rebase (same SHAs dropped); handle deleted refs instead.

Tool compatibility

• Any stateful review agent.
• GitHub / GitLab.

Variant phrasings

Rebase during inline comment drafting

Draft comments anchor to old positions - remap or drop them on SHA change.

Mid-review merge of the base branch

Same handling: the head SHA may not change, but positions can shift - revalidate.

Why it happens

Rebasing rewrites every commit SHA on the branch. State keyed to the branch name (or old SHAs) no longer matches anything, so the agent either crashes or - worse - posts comments anchored to dead positions.

Edge cases

• Restarting the review on every rebase can loop if the author rebases repeatedly; cap restarts and notify.
• Position remapping is only reliable for clean rebases; conflict resolutions need a fresh review.

Provenance

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

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

Thread query: agent lost review state when the PR was rebased mid-review

TL;DR: The agent keyed its review state to the branch name, so a mid-review rebase (new SHAs, same branch) orphaned it. Key all state to the head SHA, detect SHA changes, and resume or restart cleanly.

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:

Not specified by the original author.

TL;DR

Reopen the original PR to keep the review thread, then exempt PRs with review activity from auto-close. The agent's stale rule only looked at push dates and ignored review events, so it closed a PR a human was actively reviewing. Closing and reopening destroyed the review context for no reason.

Error

agent auto-closed an upgrade PR as "stale" while a human was mid-review, then reopened an identical one the next day

Steps

1. Reopen the original PR instead of keeping the duplicate. Reopening restores the review thread and the approved CI run. Expected: the original PR is open again with its comments intact.
2. Close the duplicate the agent opened. Leave a comment pointing at the original so nobody reviews the wrong one. Expected: one canonical PR, no confusion.
3. Re-request the review. Ping the human reviewer on the reopened PR. Expected: the reviewer picks up where they left off instead of starting over.
4. Fix the stale rule. Exempt PRs with open review requests, recent review comments, or recent human comments from auto-close; require a warning comment days before any close. Expected: the rule configuration no longer targets PRs humans are touching.
5. Change the agent's behavior. The agent should comment asking whether the PR is still needed instead of closing it outright. Expected: humans get a nudge, not a surprise close.

Use this when

• A stale bot or agent closes PRs that have active reviewers
• Reopened duplicate PRs are piling up and review history is being lost
• You are configuring inactivity rules for an upgrade-agent workflow
• A human complains their in-progress review vanished

Not for this skill when

• The PR was genuinely abandoned with no activity from anyone - closing it was correct
• The close came from a human maintainer, not automation - talk to them instead
• You want to close old PRs deliberately - do it with a warning comment first

Variant phrasings

• stale bot closed my PR during review
• agent closed upgrade PR as stale while under review
• duplicate PR opened after stale close
• how to stop auto-close on PRs with reviewers

Why it happens

Stale rules usually key off the last push or last commit date. A human reviewing a PR does not push, so a PR can look "inactive" to the bot while a reviewer has it open in another tab. The agent then closes it, realizes the work is still needed, and opens an identical PR the next day - losing the review thread, the CI history, and the reviewer's goodwill.

Edge cases

• Some platforms treat a close/reopen as resetting the mergeable state - re-run CI after reopening before merging.
• If the human's review was a "request changes," reopening keeps that state; make sure the agent addresses the feedback instead of just reopening.
• Exemptions should also cover PRs labeled "do not stale" or "wip" - humans use labels to signal intent.
• Track how often the agent's closes get reverted; a high revert rate means the stale thresholds are too aggressive.

Provenance

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

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

Thread query: agent auto-closed an upgrade PR as "stale" while a human was mid-review, then reopened an identical one the next day

TL;DR: