What is not reviewed

The boundary cases ADO Pilot skips — binaries, excluded files, target-branch filters, closed PRs, and suspended tenants.

Last updated

ADO Pilot skips some pull requests and some files inside otherwise-reviewable PRs. Knowing which is which helps you understand why a PR did not get a review, why the comment looks empty, and when a PASS does not actually mean "we looked at everything."

What gets skipped, at a glance

BoundaryBehaviorCharged review credits?
Binary files (images, archives, compiled output)Filtered before review. Never sent to the model.No.
Files matching exclusion patternsFiltered before review. Same effect as binaries.No.
PR with every changed file excludedPosts a succeeded ai-pr-review status check noting all files were excluded. No inline comment.No.
Target branch does not match targetBranchFiltersWebhook fires but ADO Pilot skips the review.No.
PR is closed, merged, or abandonedNew reviews are rejected.No.
Tenant suspended or cancelledWebhooks accepted (ADO does not retry); events dropped, not stored. New reviews rejected. In-flight reviews finish normally.No, except for in-flight reviews that already reserved quota.
enabled: false at org, project, or repoWebhook fires but ADO Pilot skips the review.No.

The rest of this page expands each row with the practical detail.

Large PRs

ADO Pilot reviews large PRs in full. There is no line-count cap that causes files to be skipped. Review quality may vary for extremely large changesets — the model has a finite context window and a very large diff competes with it — but the review attempts to cover every reviewable file.

If a PR diff cannot be processed at all (for example, due to a transient provider error or an unrecoverable internal failure), the review will fail with an error status check rather than silently returning a partial result. See No findings posted on a large PR for troubleshooting steps when a large PR produces fewer findings than expected.

Workarounds for very large PRs: split the PR into smaller change sets, or add bulk-changed paths (lockfiles, generated code, vendored dependencies) to your exclusions so they are stripped before the model sees the diff.

Binaries and irreviewable formats

Binary diffs do not contain text the reviewer can analyze, so they are filtered before review:

  • Images: .png, .jpg, .jpeg, .gif, .webp, .svg, .ico
  • Archives: .zip, .tar, .gz, .7z, .rar
  • Compiled artifacts: .exe, .dll, .so, .o, .a, .lib, .wasm
  • Media: .mp3, .mp4, .wav, .mov, .avi
  • Documents: .pdf, .docx, .xlsx, .pptx

These are silently skipped. They do not consume review credits and they do not appear in the finding count.

Excluded files

You can add your own glob patterns at three levels — org, project, or repo — under Repositories. Patterns merge across levels (the more specific scope adds to the less specific scope; nothing is overridden away).

ADO Pilot starts with an empty exclusion list for every new repo — no glob patterns are applied by default. Add patterns under Repositories for any files you want to exclude (for example, lockfiles, generated code, or vendored directories).

Glob syntax supports ** (matches across path segments, including /), * (matches anything within a single segment), and ? (matches exactly one character). Character classes ([abc]) and brace expansion ({a,b}) are not supported.

A PR where every changed file matches an exclusion pattern is a special case. ADO Pilot still marks the ai-pr-review status check as passed — so a required-branch-policy gate unblocks — with a description noting that all files were excluded. No inline comment is posted, and no review credits are consumed. This is intentional — there is nothing to review, and treating an all-excluded PR as a failure would be misleading.

Target branch filtering

Each repo can specify which target branches should trigger reviews using glob patterns — for example, ["main", "release/*"]. PRs whose target branch does not match are skipped:

  • The webhook still arrives at our backend.
  • ADO Pilot records that the event was received and then drops it.
  • No review runs, no comment posts, no review credits are charged.

Use this to keep draft branches and exploratory feature-branch chains out of the review flow.

PR lifecycle states

Reviews only run on open PRs. If a PR is merged, abandoned (closed without merging in Azure DevOps terminology), or otherwise closed:

  • The git.pullrequest.updated webhook is still received.
  • ADO Pilot detects the closed state and rejects the review.
  • A push to a closed PR is also rejected.

To get a review on a closed PR, reopen it first. See Re-running a review for the manual trigger options.

Tenant state — suspended or cancelled

If your ADO Pilot subscription is in a suspended or cancelled state — for example, a billing failure or an admin-initiated cancellation — new reviews stop:

  • Webhooks are still accepted (ADO receives a 200 so it does not retry or disable the subscription), but the events are dropped — they are not queued for replay.
  • New reviews are rejected while the tenant is suspended.
  • Reviews that had already reserved a review credit before suspension finish normally — ADO Pilot does not abandon work the customer has already paid for.
  • No review credits are consumed for the new, rejected webhooks.

The admin portal and the Overage behavior page show the suspension state and the steps to restore it.

Disabled at any scope

The enabled setting can be flipped off at the org, project, or repo level. Any enabled: false in the hierarchy gates all reviews underneath it — a disabled org disables every project and repo in that org, and a more-specific scope cannot re-enable what a broader scope has disabled. A repo with enabled: false produces no reviews even if the org and project are enabled.

What never gets flagged inside a reviewed file

A few categories of finding are intentionally suppressed even when the file is in scope:

  • Pre-existing issues in unchanged lines. ADO Pilot reviews the diff, not the whole file.
  • Mechanical formatting (indentation, brace placement, line length).
  • Issues a linter already catches, unless they signal a real bug.
  • Subjective preferences when both forms are correct (const vs let, early-return vs nested).
  • Performance concerns in test fixtures and cold administrative paths.
  • TODOs and FIXMEs the author already left as comments.

See Severities and categories for the positive scope — what does get flagged.