Skip to content

Review queue re-reviews already-approved PRs at an unchanged head #9617

Description

@kimeta

Summary

The review queue re-reviews pull requests it has already approved, with no check for whether the
head commit changed since the last approval. A pull request that cannot merge is therefore
re-reviewed once per cycle indefinitely, and each review is a full analysis-agent run in an
isolated worktree.

Evidence

PR #9580, org.springdoc:springdoc-openapi-starter-webmvc-ui:3.0.3, observed across seven cycles
of one do-work run.

The head has not moved since 2026-08-28T14:59:16Z:

headRefOid: 9295615b1fe76261ac71b7202a1ae29bd006c36f
last commit: 2026-08-28T14:59:16Z  9295615b1f

Approvals on that unchanged head:

submitted author state
2026-08-29T00:05:50Z kimeta APPROVED
2026-08-29T04:51:13Z kimeta APPROVED
2026-08-29T05:25:58Z kimeta APPROVED
2026-08-29T08:01:52Z kimeta APPROVED
2026-08-29T09:39:15Z kimeta APPROVED

Nine reviews in total, every one APPROVED, every one by the same author. Five of them landed
after the last commit, so the reviewed content was byte-identical each time. The pull request is
still open.

Why it never leaves the queue

mergeable:        CONFLICTING
mergeStateStatus: DIRTY

It cannot merge (see #9601), so it stays open, stays eligible for the review queue, and is picked
up again on the next cycle. Approving it does not change its eligibility, so the loop has no exit.

Impact

Each review spawns an analysis agent against a checked-out worktree. Five of the nine reviews on
this pull request produced no new information — the same diff, the same reviewer, the same
verdict. Any pull request blocked from merging accumulates these indefinitely, and the review
budget spent on them displaces pull requests that have not been reviewed at all.

The approval history also becomes hard to read: nine identical approvals give a reviewer no signal
about what, if anything, changed between them.

Suggested handling

  1. Skip a pull request when the configured reviewer has already submitted a review at the current
    head SHA. The codebase already threads head SHAs through this area — gh pr merge is invoked
    with --match-head-commit — so the value needed for the comparison is at hand.
  2. Re-review when the head moves, which is the case the current behavior is presumably aiming at.
  3. Consider excluding CONFLICTING pull requests from the review queue entirely until they are
    mergeable, since a review cannot advance them.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    Status
    In Progress

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions