Sign up
View stargazersSign up

[Bug]: Azure DevOps pull request Code tab never loads when the pull request changes many files#27329

opened16d agobyHhmarquez-solutions

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Add a project whose remote is an Azure DevOps repository (signed in through az login with the azure-devops extension).
  2. Open an Azure DevOps pull request that changes a few dozen files or more.
  3. Open the Code tab.

Expected behavior

The first files' diffs appear within a few seconds, and later files load as you scroll.

Actual behavior

The tab shows "Loading pull request diff..." and never renders. Smaller pull requests load, but slowly (7–19s in my traces).

Impact

Major degradation or frequent failure

Version or commit

Desktop app 0.1.5 (Beta)

Environment

Windows 11 Pro, desktop app with the bundled local server, Azure CLI 2.91.0 with azure-devops extension 1.0.10

Logs or stack traces

From server.trace.ndjson, one Code tab load:

  • environment.pullRequests.diff (POST /api/pull-requests/diff) ends Interrupted at 60,005 ms, which matches the client's diff timeout (DEFAULT_PULL_REQUEST_DIFF_TIMEOUT_MS = 60_000 in packages/client-runtime/src/state/pullRequestDiffHttp.ts).
  • Under it, AzureDevOpsPullRequestProvider.diffScope took 25.6s, listIterationChanges 3.7s, and only one readItemContent finished (5.5s). Seven more were interrupted after about 30s each.
  • Starting az alone takes about 2.5s on this machine, and the same trace shows the background pull request list running az 331 times at the same time (6s average).

Diagnosis

AzureDevOpsPullRequestProvider.getDiff builds the first diff page by reading both sides of every changed file, using one az devops invoke process per side. It can read up to MAX_DIFF_SLICE_FILES (300) files before it returns anything. With az starting in seconds per call, a pull request with many files cannot finish a page within the client's 60s limit. The client then cancels the request and the tab never gets its first page. Paging already works through the diff cursor; a page just never stops early enough to use it.

Investigated with Claude Opus 5.5 in T3 Code (Claude Code harness).

JJulius Marminge2d ago

I tried to reproduce this on the current build and could not.

Not run against a live Azure DevOps org: no worker has an Azure DevOps organisation or az sign-in. Reproduced instead with a unit test on origin/main 6f21b0f02a in packages/source-control-azure-devops/src/server/AzureDevOpsPullRequestProvider.test.ts. The test mocks AzureDevOpsPullRequestCli with 200 changed files, and each readItemContent sleeps 2.5s (the reporter's measured az startup time). It forks provider.getDiff and moves the TestClock forward 60s (the client's DEFAULT_PULL_REQUEST_DIFF_TIMEOUT_MS). The first page is still pending, so the test fails. As a check, the same test passes when the clock moves 130s and fails at 120s, so the first page takes about 125s: 50 sequential batches of 4 files at 2.5s each. This is the mechanism behind the reporter's trace, where the request was interrupted at 60,005 ms with readItemContent calls still running.

Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.