review requested from codeowners but no review submitted: PR stuck

Not specified by the original author.

TL;DR

CODEOWNERS auto-requested reviewers who never responded. Ping them directly, request specific individuals instead of the whole team, or check that the CODEOWNERS patterns actually match your changed files.

Error

Review requested from @org/team  -  2 of 2 required reviews pending, no activity for 6 days.

Steps

1. Check what CODEOWNERS matched: the PR shows which rule requested which team. Expected: you see the owning team for your files.
2. Request specific people, not just the team - team requests notify everyone and therefore no one. Expected: named reviewers get notified.
3. Ping in the team's channel with the PR link and what you need reviewed. Expected: a reviewer picks it up.
4. If the team is wrong for the files, fix the CODEOWNERS pattern in a separate PR. Expected: future PRs route to the right owners.

When to use

• CODEOWNERS requested reviews that never arrived and the PR is stuck.
• The owning team exists but is unresponsive.

When not to use

• The CODEOWNERS file itself has a syntax error - fix the file first.
• Reviews were requested from individuals who responded; the block is elsewhere.

Tool compatibility

• GitHub / GitLab code owners.
• Any repo with a CODEOWNERS file.

Variant phrasings

CODEOWNERS matched the wrong team

Patterns are last-match-wins; reorder or narrow the patterns.

Team has no active members

Update the team roster or the CODEOWNERS entry.

Why it happens

CODEOWNERS routes review requests by file path, but a request is just a notification - nothing compels a response. PRs stall when the request goes to a large team or to people who no longer own the code.

Edge cases

• Do not dismiss the requirement by removing the CODEOWNERS entry in the same PR; that is a policy change needing its own review.
• Some orgs let you proceed after N days with no response - know your policy before waiting indefinitely.

Provenance

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

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

Thread query: review requested from codeowners but no review submitted: PR stuck

TL;DR: CODEOWNERS auto-requested reviewers who never responded. Ping them directly, request specific individuals instead of the whole team, or check that the CODEOWNERS patterns actually match your changed files.

Not specified by the original author.

TL;DR

Someone owns the files this PR touches, and none of them has approved. Find the owners in CODEOWNERS, request a review from one of them, and get an actual approval. Comments do not count. If the wrong people are listed, fix the CODEOWNERS patterns.

The error

at least 1 approving review is required from code owners: how to fix

Steps

1. List the changed files

git diff --name-only origin/main...HEAD

Expected output: the file list the ownership rule is matching against.

2. Read the CODEOWNERS file

Open .github/CODEOWNERS (also check the repo root and docs folder, which GitHub accepts as fallback locations). Expected output: the ownership patterns and the teams or users they map to.

3. Match files to owners

Remember the last matching pattern wins. Walk the changed files against the patterns to find which owner entries apply. Expected output: a concrete list of who must approve.

4. Request review from an owner

On the PR, request a review from one of the listed owners, or ping the owning team. Expected output: the owner is notified and the review request is visible on the PR.

5. Get an approval, not just a comment

The owner must click Approve. Comments, even positive ones, do not satisfy the rule. Expected output: the merge box shows the code-owner requirement as satisfied.

When to use

• The exact code-owner approval block
• A new CODEOWNERS file or new patterns just landed
• The PR touches files owned by another team

When not to use

• Plain "review required" without code owners (any approver works)
• Dismissed stale reviews (different setting)
• CODEOWNERS syntax errors (the file itself is broken)

Tool compatibility

• GitHub CODEOWNERS (documented pattern syntax)
• GitLab has an equivalent CODEOWNERS approval rule
• gh CLI for requesting reviewers

Variant phrasings

code owners approval required how to fix

Same fix. Find the owners, get one of them to approve.

CODEOWNERS not requesting reviews automatically

GitHub requests reviews from owners automatically only when the file is saved in a recognized location with valid syntax. Check both.

wrong team listed as code owner

Fix the pattern in CODEOWNERS. Ownership follows the file, so correct the mapping.

Why it happens

CODEOWNERS maps file patterns to responsible people. When a PR touches owned files, branch protection adds an extra gate: at least one of those owners must approve. It fires even when other reviewers already approved, because their approval is not from an owner.

Edge cases

• Last match wins: a broad star pattern at the end can silently override specific team patterns above it. Order matters.
• Owners who left: approvals from former members do not count if they lost access. Update the file.
• Teams as owners: any team member's approval counts, but the team must have write access to the repo.
• Global owners on every path: every PR needs that team, which can bottleneck. Scope patterns tightly.

Provenance

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

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

Thread query: at least 1 approving review is required from code owners: how to fix

TL;DR: Someone owns the files this PR touches, and none of them has approved. Find the owners in CODEOWNERS, request a review from one of them, and get an actual approval. Comments do not count. If the wrong people are listed, fix the CODEOWNERS patterns.

Not specified by the original author.

TL;DR: The loop happens because the agent fires "request review" without checking whether a request is already pending or a review was already submitted, then dismisses its own request, then starts over. Persist review state per PR (requested / submitted / dismissed, with timestamps), check the live PR state before every review action, and add a repeat-action guard that halts after the same action fires twice with no intervening change. That breaks the cycle and leaves exactly one review request per PR.

agent loop: requested review, dismissed it, requested review again

1. Read the PR's live review state first. List the PR's reviews and its requested reviewers through the API before taking any action. Expected: you see the pending request plus the review the agent already submitted or dismissed - proof the loop is recreating state that already exists.

2. Keep a small state record keyed by PR number that the agent loads at the start of every run. Store reviewrequestedat, reviewsubmittedat, and dismissed_at timestamps in it. Expected: later runs know what already happened without guessing from the API alone.

3. Gate the request-review action. Before calling it, check both the state record and the live API; if a request is pending or a review is already submitted, skip the call and log that a review was already requested. Expected: the second loop iteration logs the skip instead of firing another API call.

4. Separate dismissal from requesting. Only dismiss a review when a new commit or an explicit instruction requires it; never auto-dismiss a review the agent itself requested in the same run. Expected: dismissals stop appearing in the same action sequence as requests.

5. Add a repeat-action guard. If the last two actions on the same PR are an identical request/dismiss pair with no new commit or state change between them, halt the review task and report the loop instead of acting. Expected: the agent stops after the guard trips instead of cycling forever.

6. Re-run the review task on a test PR and inspect the action log. Expected: at most one request-review call per PR, no self-dismissal, no repeats.

Use this when

• Request-review, dismiss-review, request-review appears for the same PR in the action log
• The agent's actions repeat with no new commits between them
• Review requests pile up on a PR the agent already reviewed
• The agent dismisses reviews it created itself

Not for this skill when

• A human reviewer manually dismissed the review (check the dismissing actor first)
• The PR genuinely needs re-review after new commits were pushed (that is new state, not a loop)
• Review calls are failing with 403 or 404 (that is a permissions or existence problem)
• The agent is stuck waiting on API rate limits rather than repeating actions

Variant phrasings

• "review bot keeps requesting review after dismissing it"
• "agent stuck requesting and dismissing PR reviews in a loop"
• "duplicate review requests on the same pull request"
• "agent dismisses its own review then requests a new one"

Why it happens

Most review agents treat "make sure a review is requested" as an unconditional step with no memory of what already happened. Each run sees no review attached (because it just dismissed its own), so it requests again; then a cleanup step sees a stale pending request and dismisses it. Without persistent per-PR state and a live check before each action, request and dismiss chase each other forever.

Edge cases

• The state record goes stale if a human merges or closes the PR. Refresh from the API at the start of every run instead of trusting the file alone.
• Multiple agent instances on the same PR need a shared state store, not a local file, or each one loops independently.
• If dismissals come from the repo's "dismiss stale reviews on push" branch-protection setting, that is repository config, not an agent loop. Check repo settings before changing agent behavior.
• Guard halts should notify a human instead of silently dropping the review, or PRs will sit unreviewed.

Provenance

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

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

Thread query: agent loop: requested review, dismissed it, requested review again

TL;DR: