Mid-review pushes

When you push a new commit while ADO Pilot is mid-review, the new review queues behind the existing one — reviews for the same PR run one at a time. The review already in progress runs to completion. When several new iterations end up waiting at once, ADO Pilot makes a best-effort attempt to review only the latest one and skip the earlier (superseded) iterations before they start.

The scenario

10:00  you push commit A
10:01  review of A — queued
10:02  review of A — in progress
10:03  you push commit B
10:04  review of B — queued (waiting for review of A to finish)
10:08  review of A — complete
10:08  review of B — in progress
10:11  review of B — complete

The review of A runs fully to completion. Only then does the review of B start.

What happens to the in-flight review

When a new push arrives while a review is already in progress on the same PR, ADO Pilot queues the new review behind the in-flight one rather than starting it immediately. This means:

• The in-flight review completes normally. It is not cancelled or stopped at a checkpoint.
• ADO Pilot bills review credits for each completed review — once a review has started, it always runs to completion and is billed.
• If a newer commit superseded it while it ran, its inline comments are not posted; only the latest iteration's results post to the PR.
• The tracking comment updates in place through each review's lifecycle.

What happens to the new review

The new review starts fresh against the new commit. It leaves the queued state only after the previous review has finished.

• The same tracking comment is reused. Azure DevOps does not get a second comment thread; the existing comment's body is rewritten in place as each review progresses.
• Inline comments come only from this new review. ADO Pilot does not reopen or resolve inline comments left by an earlier iteration — if an earlier iteration was superseded while still waiting, it never posted any comments to begin with (see above).
• The ai-pr-review status check reflects the state of whichever review is currently active.

Stuck reviews

A review that has not reached a terminal state is automatically marked failed after 30 minutes. If a review was holding the queue and stopped without finishing normally, the queue clears after 90 minutes so the waiting review can proceed. In practice this is rare — a healthy review usually finishes well within that 30-minute threshold. If a review has been stuck for over 30 minutes, see Reviews stuck in "in progress" for steps to diagnose and restart it.

Why this design

Letting an in-flight review finish — rather than cancelling it — avoids partially-computed findings and an inconsistent tracking comment: a review that has started always produces a complete verdict. At the same time, when newer iterations are waiting, reviewing only the latest avoids spending review credits on code you have already moved past. Queuing keeps the review history clean: one review at a time, and the results you see always reflect the most recent reviewed iteration.

The tradeoff is that a review already in progress is never cancelled — so if you push a fix moments after a review starts, that in-progress review still runs to completion (and is billed) before the latest iteration is reviewed. Iterations that are still waiting when a newer one arrives are skipped, so a burst of rapid pushes does not queue up a long chain of billed reviews.

Concurrency limits

Queuing is specific to each pull request — reviews on different pull requests run independently and in parallel. If you push commits to multiple open PRs at once:

• Each PR's review starts immediately and runs concurrently with the others.
• Within a single PR, a mid-review push queues behind the in-progress review for that PR.

Sequencing in practice: pushes on the same PR wait for the preceding review to finish; pushes on different PRs proceed independently.