GitHub · Pull requests · Conversation resolution · Checked October 26, 2026

GitHub: the merge waits for conversations to be resolved

A branch protection rule or a ruleset can require conversation resolution before merging. Then all comments on the pull request must be resolved before it can be merged into the branch, so that all comments are addressed or acknowledged before the merge (GitHub's about protected branches and available rules for rulesets). The REST reference words the ruleset setting as "All conversations on code must be resolved before a pull request can be merged." Until then the REST mergeable_state of the pull request is blocked, and GraphQL's mergeStateStatus is BLOCKED (checked October 26, 2026).

GET  /repos/OWNER/REPO/rules/branches/BRANCH        → rule "pull_request": parameters.required_review_thread_resolution
GET  /repos/OWNER/REPO/branches/BRANCH/protection   → required_conversation_resolution.enabled
POST /graphql   pullRequest(number: N) { reviewThreads(first: 100) { nodes { isResolved isOutdated viewerCanResolve path line } } }

Which conversations count

Conversations on code: the ones that can be resolved are the threads on the Files changed tab, which start from a comment on the changed code; "Resolve conversation" collapses the whole thread and marks it resolved (GitHub's commenting on a pull request). The API calls them review threads, each with isResolved.
Outdated ones too: a conversation can be outdated by newer changes and still not resolved: the API reports isOutdated and isResolved separately. The Conversations menu on the Files changed tab lists unresolved, resolved and outdated conversations, which makes the open ones easy to find (see why a comment is outdated).
Where the rule is: in a branch protection rule, "Require conversation resolution before merging"; in a ruleset, the pull request rule's required_review_thread_resolution, which "Get rules for a branch" returns among the active rules for the branch. Several rulesets can apply to one branch at once.

Who can resolve a conversation

The author or a writer: you can resolve a conversation if you opened the pull request or if you have write access to the repository. Others, including the reviewer who started it without write access, cannot; GraphQL's viewerCanResolve says whether you can.
Through the API: GraphQL's resolveReviewThread and unresolveReviewThread take the thread's node id. A workflow's or app's token needs more than pull requests permission for them (see why a conversation was not resolved).
Admins: by default the restrictions of a branch protection rule do not apply to people with admin permissions or roles with the "bypass branch protections" permission, unless "Do not allow bypassing the above settings" is on; they can merge while others wait.

What to do

Find the open ones: on the Files changed tab, open the Conversations menu, or list the review threads through GraphQL and keep those with isResolved false.
Answer, then resolve: address each comment, or reply to it, and resolve it as the author or someone with write access. A conversation that is out of the pull request's scope can become a new issue linked back to the comment, and then be resolved.
Ask the one who can: if you can neither resolve it nor bypass the rule, ask the pull request's author or a maintainer with write access.
Check the other rules: resolution is one requirement among others: approving reviews (see a code owner's review and why an approval does not count), required checks (see a required check stuck at "Expected"), a branch that must be up to date.

In IntelliJ IDEA: the threads are read, the rule is not

How the GitHub support built into IntelliJ IDEA deals with resolving conversations, in its source (checked October 31, 2026; IntelliJ IDEA: refUpdateRule.graphql, pullRequestReviewThreads.graphql, pullRequestReviewThread.graphql, GHPRTimelineThreadViewModel.kt, GHPRReviewServiceImpl.kt, GraphQL files):

Not the rule: none of its 78 GraphQL files asks whether the branch requires conversations to be resolved (requiresConversationResolution in branch protection, requiredReviewThreadResolution in a pull request rule), and the rule it reads for the base branch has neither.
The threads: it asks for the pull request's review threads, 100 at a time. For each one it asks whether it is resolved or outdated, its file and lines, up to 100 comments, and whether your account can reply, resolve or unresolve it.
Resolving: in its timeline thread code, whether the state can be changed comes from GitHub's answer on whether your account can resolve or unresolve that thread, and a change is sent as GitHub's resolveReviewThread or unresolveReviewThread.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows the conversations on the diff, marks the resolved ones with who resolved them, and offers Resolve and Unresolve; it reads the threads through GraphQL with your token. When GitHub calls the pull request blocked, its merge checks say the rules of the target branch are not met yet (required reviews or required checks). When a blocked pull request has conversations on code that are not resolved, they are counted there, and said to hold the merge back when the target branch's ruleset or protection requires them resolved; when those rules cannot be read, as what may hold it back. The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.