Azure DevOps PR details fail from chat with "The change request does not belong to the selected project"
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 23k
- Forks
- 5.9k
- Avg merge
- 11h 14m
- Merged PRs (30d)
- 357
Description
What happened
my problem is that i cant view azure devops pull requests, its linked but i cant see any details
Opening the PR from the Pull Requests page works. Opening the same PR from a chat/thread (the linked PR pill, or an ADO PR link in the conversation) shows no details — detail, activity, and diff all fail.
Diagnosis
Client and server disagree about how an Azure DevOps repository is named in a PullRequestRef, so the server's ownership check rejects every detail read that originates from a thread:
- The server names an ADO repository by its bare name (e.g.
myrepo):repositoryIdentityOfinapps/server/src/pullRequest/PullRequestService.ts:485special-casesazure-devopsbecauseaz repos pr list --repositorytakes a name, not a path. - The web client, on the thread-origin paths, sends
repositoryIdentity.displayNameinstead, which for ADO is the full remote pathorg/project/_git/repo:apps/web/src/components/ChatView.tsx:3333(threadRepository, used by the thread's PR pill), andapps/web/src/lib/openPullRequestLink.ts:246(ADO PR links clicked in chat).
requireProject(apps/server/src/pullRequest/PullRequestService.ts:638) compares the two strings, which can never match for Azure DevOps, and fails withresolveRepository: The change request does not belong to the selected project.— before any provider call is made.
The Pull Requests page is unaffected because its rows carry the server-produced repository name (PullRequestRow.tsx:115 uses entry.repository), which round-trips correctly. GitHub/GitLab are unaffected because their repositoryIdentityOf result is the displayName.
Steps to reproduce
- Add a project whose git remote is an Azure DevOps repo (
https://dev.azure.com/{org}/{project}/_git/{repo}), with ADO PR support set up. - Start a session on a branch with an open PR so the thread shows the linked PR pill (or have an ADO PR URL in the chat).
- Click the PR pill or the PR link in chat.
- The PR panel opens but detail/activity/diff fail with the error above. Opening the same PR from the Pull Requests page works.
Version
0.0.34-nightly.20260820.1141 (commit f708f63, current main — bug is present in latest source)
Environment
Windows 11 Pro (10.0.26200) x64, Node v24.15.0, desktop app (Electron) against local server
Evidence
ws.rpc.pullRequests.detail -> Failure:
PullRequestOperationError: Pull request operation resolveRepository failed: The change request does not belong to the selected project.
at ws.rpc.pullRequests.detail (.../resources/server.asar/apps/server/dist/bin.mjs:76917:104)
ws.rpc.pullRequests.activity -> same failure
POST /api/pull-requests/diff -> 502, same failure
(no pullRequests.list calls in the trace — failures originate from the thread's right-panel surface, not the PR page)
Related issues
PR #7316 fixes the az CLI layer for full-path repository names; it does not address this mismatch, which fails in requireProject before any az call. No existing issue mentions this error string.
Fix applied or workaround
None applied. Workaround confirmed by the user: open the PR from the Pull Requests page instead of the chat/thread.
Filed by
Claude Fable 5 (claude-fable-5) via t3 triage
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect repositoryIdentityOf and requireProject in apps/server/src/pullRequest/PullRequestService.ts, then compare the thread-origin values from apps/web/src/components/ChatView.tsx and apps/web/src/lib/openPullRequestLink.ts. Reproduce the failure from a chat PR pill or ADO link, and verify that detail, activity, and diff work there while the Pull Requests page remains working.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, typescript
- Domain
- backend-api-design, frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100