Mid-review pushes

What happens when you push a new commit while an ADO Pilot review is in flight — the in-flight review is abandoned and a fresh review starts against the latest commit.

Last updated

When you push a new commit while ADO Pilot is mid-review, the in-flight review is abandoned and a fresh review starts against your latest commit. The tracking comment updates in place, and you are not charged a review credit for the abandoned run.

The scenario

10:00  you push commit A
10:01  review of A — queued
10:02  review of A — in progress (Pass 1)
10:03  you push commit B
10:04  review of A is abandoned; review of B — queued
10:05  review of B — in progress
10:08  review of B — complete

You only ever see findings from the latest commit's review. The intermediate review never produces a comment update past the in-progress placeholder.

What happens to the abandoned review

When the orchestrator detects that a newer commit has arrived on the same PR:

  • The in-flight review stops at the next checkpoint. Pass 1 is cancelled if it has not finished; Pass 2 never runs.
  • No findings post from the abandoned review. The tracking comment is left in place because the new review will overwrite it within seconds.
  • ADO Pilot does not bill review credits for the abandoned run. Billing is tied to a completed review, not to the work the orchestrator did.
  • The abandoned review is recorded internally with a terminal state of "superseded" so support can trace it if needed.

What happens to the new review

The new review is a fresh orchestration against the new commit. It is not a continuation of the old one — it starts from queued, runs Pass 1 from scratch, and runs Pass 2 from scratch.

  • The same tracking comment is reused. Azure DevOps does not get a second comment thread; the existing comment's body is rewritten in place.
  • Inline comments from the abandoned review (if any had posted, which they normally have not by the time you push) are reconciled against the new findings: confirmed findings are kept, rescinded ones are resolved.
  • The ai-pr-review status check on the PR drops back to Pending until the new review completes.

Why this design

Reviewing stale code is wasted effort. By the time the abandoned review would have finished, you have already moved past whatever it was about to flag — the line numbers may have shifted, the variable names may have changed, the fix may already be in. Posting findings against the previous commit creates noise and confusion. Abandoning and restarting keeps the PR timeline clean: one tracking comment, one set of inline findings, one verdict, all referencing your latest code.

The cost is that you cannot see what Pass 1 was about to flag in the abandoned commit. In practice this rarely matters — if you push a fix while the review is running, the issue you fixed was probably what the review was about to flag anyway.

Concurrency limits

The mid-PR fast-path (abandon and restart) is unrelated to the cross-PR concurrency limit. ADO Pilot processes one review at a time per organization by default; per-org concurrency limits may evolve with plan tier. If you push commits to multiple open PRs at once:

  • The first PR's review starts immediately.
  • The second PR's review queues until the first finishes.
  • Within either PR, a mid-review push still abandons and restarts immediately — that path bypasses the cross-PR queue.

Sequencing in practice: pushes on the same PR are always fast (no queue wait), but a brand-new review on a different PR may wait briefly for the org's review slot.