401 error when trying to resolve discussions in PRs

[Flamefire]

Select Topic Area

Question

Body

I reviewed a quite large PR with many open threads that fail to show inline, so I opened the comments side-panel.

When trying to resolve a thread (click check mark at top right) I get an error

Failed to resolve thread

Network inspector shows a seemingly correct POST request to resolve_thread with the threadid POST param set but I get a HTTP 401 - Forbidden back with

User is not authorized to resolve the conversation

So a better error would be good if information like that is available.

The actual issue might be cause by either:

1. In the "conversation" tab all threads are shown as resolved so it might try to resolve a resolved thread. Then it would (additionally to the misleading return code) a bug in the comments side-panel to show that discussion as unresolved with the filter set to not show them
2. "Jump to comment in diff" leads to a "commit range not found" page as the author force-pushed. However the "conversation" tab still has those threads. Couldn't it go there?

[Navyansh999]

A 401 – “User is not authorized to resolve the conversation” usually means one of two things: either you don’t have permission to resolve that thread, or the thread is tied to an outdated commit after a force-push.

On GitHub, only users with write access (or higher) to the repository can resolve review threads. If you’re just a reviewer without write permissions, GitHub blocks the action and returns 401 — even if the UI doesn’t clearly say so.

The second likely cause is the force-push. When the author rewrites history, some review threads become attached to commits that no longer exist. That’s why “Jump to comment in diff” shows “commit range not found.” In that state, the UI may still show the thread in the side panel, but backend validation can fail when trying to resolve it.

[Flamefire]

In both cases I'd like to have a better error message than the generic one currently shown.

[Navyansh999]

That’s completely reasonable. A generic 401 like “Failed to resolve thread” doesn’t help much when the real issue could be permissions, an already-resolved thread, or a force-push breaking the diff context.

A better UX would clearly state the actual cause, for example:

• “You don’t have permission to resolve this conversation.”
• “This thread is already resolved.”
• “This thread is attached to an outdated commit after a force-push.”

Clear, specific errors reduce confusion and save debugging time. This sounds more like a product feedback / UX improvement request rather than a user mistake, and it would be valid to raise it as feedback so the platform can surface more descriptive error messages.

[MasteraSnackin]

This looks less like a permissions problem and more like a state/UX bug in the PR review UI.

Both of your hypotheses are very plausible:

• In the Conversation tab the threads are already resolved, so the side panel is likely trying to resolve something that is already resolved. In that case, returning a 401 with "User is not authorized to resolve the conversation" is misleading – the thread is just in an invalid state for that action, not forbidden. A 4xx with a clearer message (e.g. "Thread already resolved" or "Thread state changed, please reload the page") would make more sense.
• The "Jump to comment in diff" pointing at "commit range not found" suggests the side panel is still bound to a stale commit range that disappeared after a force-push. The Conversation tab still has the discussion, so the UI should either re-anchor those comments to the updated diff, or fall back to showing them in the Conversation view instead of failing with a 401.

So my understanding is:

1. The backend is probably rejecting the resolve call because the thread/diff context no longer matches what the client thinks, not because of missing permissions.
2. The client is surfacing that as a generic 401 "not authorized" instead of a more specific "thread already resolved or no longer valid for this diff" error.
3. The side panel is out of sync with the real state (showing unresolved when the Conversation tab shows resolved).

A fix would likely involve:

• Making the API return a more specific error for "already resolved/invalid diff context" instead of 401, and
• Updating the side panel to sync its state with the Conversation tab (and to route those comments to Conversation when the original commit range is gone after a force-push).

If you can share PR/thread IDs with GitHub Support, they should be able to confirm this and potentially link it to an existing internal issue.

[Flamefire]

Fully agreed, both with your analysis (I suspected the same) and your suggested fixes. That would be great having, especially the rerouting of threads.

In case GitHub Support looks here: POST is to https://github.com/Return-To-The-Roots/s25client/pull/1720/page_data/resolve_thread with data {"threadId":"1866328590"}

[Himanshu8728]

This looks like a combination of permission constraints and UI inconsistency rather than a client-side issue.

1. Permission check (main cause of 401)
GitHub only allows resolving conversations if the user has write access to the repository (e.g., PR author or collaborator). If you’re reviewing without write permissions, the backend correctly returns 401, but the UI still shows the resolve button, which is misleading.

2. Already resolved thread (UI sync issue)
You mentioned that the "Conversation" tab shows the threads as resolved while the side panel shows them as unresolved. In that case, the request is likely attempting to resolve an already resolved thread, which results in failure. This indicates a UI desynchronization bug between views.

3. Force-push breaking thread context
The “commit range not found” error suggests the PR author force-pushed changes. When that happens:

• The original diff context is lost
• Threads remain in the Conversation tab
• Some actions (like resolving from outdated context) may fail

Workarounds:

• Verify you have write access to the repo
• Use the "Conversation" tab to confirm actual thread state
• Refresh the page or reload the PR to resync UI
• Avoid resolving threads tied to outdated diffs (after force-push)

Suggested improvements:

• Disable "Resolve" button for users without permission
• Return a more specific error (e.g., “Insufficient permissions” vs generic 401)
• Sync thread state consistently between side panel and conversation view
• Handle force-pushed commits more gracefully (fallback to conversation view)

Overall, this seems like a GitHub UX issue rather than an issue with the request itself.

[Flamefire]

Avoid resolving threads tied to outdated diffs (after force-push)

That's not really visible to the user at that place

Overall, this seems like a GitHub UX issue rather than an issue with the request itself.

Yes.
I'm fine with having the resolve Icons there if they are also in the conversation tab (are they? Can't remember a case where I didn't had the necessary permissions).
But then the error should be clear about that. Having the icon that then errors avoids people wondering where they are. Maybe disable them with a tooltip to avoid useless requests.

[Himanshu8728]

That makes sense — thanks for pointing that out.

If the outdated diff context isn’t visible to the user at that point, then expecting them to avoid resolving those threads isn’t really practical. In that case, it strengthens the argument that this should be handled on GitHub’s side.

Showing the resolve action but failing with a generic error is definitely confusing. Disabling the button (or showing a tooltip explaining why it can’t be resolved — e.g., missing permissions or outdated context) would make the behavior much clearer and avoid unnecessary requests.

Agree that improving the error message and UI feedback here would significantly improve the experience.

[Kumailabbass]

This appears to be an authorization/state mismatch, not just a UI issue.

From your description, likely causes are:

The thread is already marked as resolved in the backend, but the side-panel still shows it as unresolved (state sync issue).

You don’t have permission to resolve the thread (e.g., not the PR author or lacking write access), which explains the 401 – “User is not authorized to resolve the conversation.”

The PR was force-pushed, and the original commit range no longer exists, causing:

“Jump to comment in diff” → commit range not found

Threads still visible in the Conversation tab but detached from the current diff.

Suggested improvements:

Show a clearer error message when permission is the actual cause.

Sync resolved state correctly between Conversation tab and side-panel.

If commit range is gone, redirect to the Conversation view instead of a broken diff link.

[ES-Alexander]

The permissions aspect of this was raised ages ago in #8327 🥲

[AndiDog]

This is wasting me so much time for a simple, medium-sized PR with some 20 comments. I can't resolve my own comments and therefore don't have a good overview of how much I reviewed.

Together with "Only the latest 40 comments are currently being shown. To view the remaining comments, open the comments side panel", which forces me to jump between side panel and code all the time, it's an absolute mess.

The error HTTP 401 "User is not authorized to resolve the conversation" is clearly not correct. All comments shown in the side panel must be resolveable. I definitely have write access to the repo, and I'm the comment author. I'm also seeing this without force-pushes.