Open threads must be resolved: how to resolve GitLab merge request threads

By Melih Toksari, developer of MergeBell · Updated 27 October 2026 · 3 min read

Every other check passes, and the merge request still won’t merge: GitLab lists “Open threads must be resolved.” among its merge checks. Someone left a comment thread that’s still open, and the project requires every thread to be settled first. Here is what counts as a thread, how to resolve one, and what to do when a thread can’t be settled now.

What the message means

The merge check appears when two things are true:

The project requires it. All threads must be resolved is turned on in the project’s merge checks. It’s off by default.
A thread is still open. Comments on a line of the diff are threads, and so are comments started with Start thread. A standard comment, the default in the comment box, isn’t a thread and doesn’t block, until someone replies to it: the first reply turns it into one.

Next to the message, Go to first open thread takes you straight to one. In the API, the merge request’s detailed_merge_status reads discussions_not_resolved.

Resolve a thread

You need the Developer role or higher, or to be the merge request’s author or the person who started the thread. Then either:

in the upper-right corner of the thread’s first comment, select Resolve thread,
below the last reply, select Resolve thread, or
write a reply, select its Resolve thread checkbox, then Add comment now.

A resolved thread collapses, and people can still comment on it. To bring it back, expand it and select Reopen thread. Applying a suggestion resolves its thread too.

Find the open ones

The Open threads counter in the upper right of the merge request shows how many are left. It turns orange while the check is blocking. Its Thread options menu has Show all comments and, while threads are open, Resolve all with new issue.
The keyboard: n moves to the next open thread, p to the previous one.

Not ready to settle it? Move it to an issue

A thread can matter without blocking this merge request. GitLab can turn open threads into an issue and resolve them:

One thread: below its last reply, next to Resolve thread, select Create issue to resolve thread.
Every open thread: in the Open threads menu, select Thread options › Resolve all with new issue.

Fill in the issue and select Create issue. GitLab resolves the threads and links the merge request to the new issue.

Let pushes resolve outdated threads

In Settings › Merge requests › Merge options, Automatically resolve merge request diff threads when they become outdated resolves a diff thread when a push changes the lines it’s about. Threads on unchanged lines, and threads that aren’t on the diff, stay open.

Turn the check on or off

A Maintainer or Owner turns it on in Settings › Merge requests: under Merge checks, select All threads must be resolved, then Save changes. On Premium and Ultimate, an Owner of the top-level group can enforce it for every project in the group, and those projects can’t turn it off. With it on, auto-merge waits for the threads as well. Through the API, it’s the project attribute only_allow_merge_if_all_discussions_are_resolved.

From the command line or the API

The GitLab CLI can list and resolve threads; both commands are marked experimental:

glab mr note list 42 --state unresolved
glab mr note resolve 42 abc12345

list shows an eight-character prefix for each thread, which resolve accepts. With the API, list a merge request’s threads, then resolve one by its ID:

curl --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/merge_requests/42/discussions"

curl --request PUT \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/merge_requests/42/discussions/<discussion_id>?resolved=true"

On the merge request itself, blocking_discussions_resolved is true when open threads aren’t holding up the merge: either they’re all resolved, or the project doesn’t require it.

Threads on your phone

Most threads end with a short reply: “fixed in the last push”, “agreed, done”. In MergeBell, replying to a thread and resolving it are part of the free tier, on iPhone and Android, and the merge sheet lists open threads among the reasons it can’t merge yet, before you tap Merge. For everything else that can block a merge, see why can’t I merge my GitLab merge request?

Frequently asked questions

Why does GitLab say "Open threads must be resolved"?

The project has the All threads must be resolved merge check turned on, and at least one thread in the merge request is still open. Resolve the open threads, or move them to an issue, and this check passes.

Who can resolve a thread in a GitLab merge request?

Anyone with the Developer, Maintainer or Owner role, the merge request's author, and whoever started the thread. Anyone who can resolve a thread can also reopen it.

How do I find the open threads?

Use the Open threads counter in the upper right of the merge request, or Go to first open thread in the merge checks. On the keyboard, n moves to the next open thread and p to the previous one.

Can I merge without resolving every thread?

Move them to an issue: Thread options › Resolve all with new issue resolves every open thread and links the merge request to the new issue. Otherwise a Maintainer can turn off All threads must be resolved in Settings › Merge requests, unless the top-level group enforces it, on Premium or Ultimate.

Do threads resolve themselves when the code changes?

Only when the project turns on Automatically resolve merge request diff threads when they become outdated, and then only diff threads whose lines a push changes. Applying a suggestion also resolves its thread.