agent diff fetch 404d: PR branch deleted mid-review

Not specified by the original author.

TL;DR

The PR branch was deleted while the agent was reviewing, so diff fetches 404. Treat branch-deleted as a terminal state: stop the review, clean up partial state, and log why - do not retry the fetch.

Error

Agent log: GET /repos/acme/app/compare/main...feature-x → 404 Not Found (branch deleted mid-review).

Steps

1. Confirm the cause: the PR timeline shows the branch was deleted during the run. Expected: a delete event, not an API outage.
2. Handle the 404 explicitly: catch it on diff fetch and check whether the PR is merged/closed. Expected: the agent knows the review is moot.
3. Stop cleanly: discard partial review state and log 'branch deleted, review abandoned'. Expected: no crash, no partial review posted.
4. Do not retry the fetch in a loop - the branch is gone, not slow. Expected: the run ends instead of spinning.

When to use

• The agent's diff fetch 404s because the PR branch was deleted mid-run.
• The agent fetches diffs itself.

When not to use

• The PR itself 404s (deleted PR) - handle that as a separate case.
• The 404 is transient API flakiness; that deserves a retry.

Tool compatibility

• GitHub / GitLab compare/diff APIs.
• Any agent fetching PR diffs.

Variant phrasings

Branch deleted after merge

The normal case - the review is simply moot; stop quietly.

Branch force-deleted by accident

The PR can be restored; the agent should still stop and let a human decide.

Why it happens

Deleting the branch removes the diff the agent is reviewing. Retrying a 404 for a deleted ref never succeeds - the correct response is to recognize the terminal state and stop, not to hammer the API.

Edge cases

• Distinguish 'branch deleted' from 'never existed' - the latter is a bug in ref resolution, worth an alert.
• Partial reviews already posted stay posted; note in the log what was abandoned.

Provenance

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

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

Thread query: agent diff fetch 404d: PR branch deleted mid-review

TL;DR: The PR branch was deleted while the agent was reviewing, so diff fetches 404. Treat branch-deleted as a terminal state: stop the review, clean up partial state, and log why - do not retry the fetch.

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

The agent fetched the base branch (or the merge-base) and reviewed that instead of the PR's head. Resolve the head SHA from the PR API and diff base...head explicitly before reviewing.

Error

Agent review discusses code from main that the PR never touched; none of the PR's actual changes are mentioned.

Steps

1. Confirm: compare the review's claims against the PR's files-changed list. Expected: the review describes base-branch code.
2. Fix the ref resolution: get head.sha from the PR API response and check out / fetch exactly that SHA. Expected: the agent sees the PR's code.
3. Compute the review diff as base...head (three-dot), not base..head - three-dot shows what the PR introduces. Expected: the diff matches the PR page.
4. Re-run the review. Expected: findings reference the PR's actual changes.

When to use

• The agent's review discusses code the PR did not change.
• The agent checks out code itself.

When not to use

• The review is on an old head SHA - that is staleness, not the wrong branch.
• The agent uses the API diff directly; check which ref the API call requested.

Tool compatibility

• Any agent that clones/fetches PR code.
• GitHub / GitLab.

Variant phrasings

Agent reviewed the merge commit

The merge commit includes base changes; review the head diff instead.

Fork PRs: agent fetched the wrong remote

Fork heads live on the fork remote - add it and fetch the PR ref explicitly.

Why it happens

Default clones and naive fetches land on the base branch. Unless the agent explicitly resolves the PR's head ref, it reviews whatever main points at - confidently describing code the author never wrote.

Edge cases

• Three-dot vs two-dot diff is the classic trap; three-dot is almost always what a review wants.
• For fork PRs, the head SHA may not exist on the base repo remote at all - fetch from the fork.

Provenance

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

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

Thread query: agent reviewed the base branch instead of the head ref

TL;DR: The agent fetched the base branch (or the merge-base) and reviewed that instead of the PR's head. Resolve the head SHA from the PR API and diff base...head explicitly before reviewing.