fix(azure-devops): pull request Code tab loads when the pull request changes many files#27331

External image Major · Stability & Availability · Heavy lift

Stop waiting for the entire batch before applying the budget.

The first batch contains four changes. Each file can perform two concurrent Azure CLI reads, and the four file reads run concurrently. Effect.forEach returns only after the complete batch finishes, so the 15-second budget check cannot bound the first batch.

The scope lookup and change-list read also occur before the batch. Slow CLI operations can therefore exceed the client’s 60-second request window before getDiff returns a cursor.

Bound in-flight reads against the remaining request time. Return completed files with the current cursor so later files can load on the next request. Preserve the intentional behavior that reads at least one batch and keep the existing byte, edit, and file caps.

Thanks. I checked this and am keeping the batch-level check rather than bounding in-flight reads:

• Reads in a batch run at the same time, so a batch lasts about as long as its slowest file. Interrupting the rest of the batch saves little.
• A page must return at least one file, or the Code tab stops paging: PullRequestCodeTab.tsx only loads the next page when nextCursor !== cursor. So a page can't give up before its first file finishes.
• The setup reads (location, iterations, change list) happen on every page. They do count toward the 15s budget, because startedAt is taken before them, but no change in the loop can skip them.

So the worst case is setup plus one file's reads, with or without interrupting a batch. The bug in #27329 was a page reading up to 300 files before answering, and the budget fixes that. A hard 60s bound would need a defined result for a page where no file finishes in time, which is a larger change than this fix. An independent review (GPT-6.1 Sol) reached the same conclusion.

@hmarquez-solutions You’re right. I withdraw this finding.

The supplied code starts the clock before setup and checks the budget after each batch. This limits additional batches while preserving cursor progress. It does not guarantee a hard request deadline, but that distinction does not make the batch-level check defective.

My recommendation imposed a stronger timeout contract than this fix requires. A hard deadline needs defined behavior when no file completes, as you noted. No in-flight cancellation change is needed for this finding.

📝 Learnings were not changed: only organization members or users with write access to this repository can add or remove learnings.

Review thread resolved.

_{You are interacting with an AI system.}