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): repositoryIdentityOf in apps/server/src/pullRequest/PullRequestService.ts:485 special-cases azure-devops because az repos pr list --repository takes a name, not a path.
- The web client, on the thread-origin paths, sends
repositoryIdentity.displayName instead, which for ADO is the full remote path org/project/_git/repo:
apps/web/src/components/ChatView.tsx:3333 (threadRepository, used by the thread's PR pill), and
apps/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 with resolveRepository: 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
What happened
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:myrepo):repositoryIdentityOfinapps/server/src/pullRequest/PullRequestService.ts:485special-casesazure-devopsbecauseaz repos pr list --repositorytakes a name, not a path.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:115usesentry.repository), which round-trips correctly. GitHub/GitLab are unaffected because theirrepositoryIdentityOfresult is the displayName.Steps to reproduce
https://dev.azure.com/{org}/{project}/_git/{repo}), with ADO PR support set up.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
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