Azure DevOps Integration Bug: Too Many Work Items!

by ADMIN 51 views

Hey guys,

We've got a bit of a situation with the Azure DevOps integration, specifically when dealing with a large number of work items. It seems like there's a limit that's causing some headaches, and I want to break down the issue, how to reproduce it, and some potential improvements. Let's dive in!

Describe the Bug

So, the core issue is this: when you're trying to fetch tasks for your task list in Rider (or a similar IDE), the Azure DevOps integration throws a fit if your project has more than 20,000 work items, especially when you've checked the "Include issues not assigned to me" option. This is a problem because it prevents you from seeing all the tasks you might need to be aware of, even if they're not directly assigned to you. This can lead to missed deadlines and confusion about project status.

The error message you'll likely encounter is a warning that says, "Cannot connect to [your Azure DevOps URL]," followed by a more detailed error in the Rider log file. This error basically says that the query is returning too many work items and exceeding the allowed limit.

This limitation severely impacts the usability of the Azure DevOps integration for larger projects. Imagine trying to manage a complex software project with thousands of tasks, only to be blocked by this arbitrary limit. It's like trying to drink from a firehose – not a pleasant experience.

To Reproduce

Here’s how you can recreate this bug:

  1. Add an Azure DevOps task list server to your IDE (like Rider). This is the standard process of connecting your IDE to your Azure DevOps organization.
  2. Check the "Include issues not assigned to me" option. This is the key step that triggers the bug when the project has a large number of work items.
  3. Go to 'Open Task...' or the equivalent function in your IDE that allows you to browse and select tasks from Azure DevOps.
  4. Observe the warning "Cannot connect to [your Azure DevOps URL]" and check the Rider log file for the detailed error message.

If your Azure DevOps project has more than 20,000 work items (including closed, completed, and other states), you should consistently see this error. It's a pretty reliable way to break the integration, unfortunately.

Expected Behavior

Ideally, the integration should display a list (or at least a subset) of open work items, regardless of the total number of work items in the project. This could involve:

  • Pagination: Displaying work items in smaller chunks, allowing users to browse through them page by page.
  • Filtering: Providing more robust filtering options to narrow down the list of work items to a manageable size.
  • Optimized Querying: Improving the efficiency of the query to fetch only the necessary data, avoiding the size limit.

Instead of crashing and burning, the integration should gracefully handle large projects and provide a usable experience for developers.

Observation

Interestingly, even though the error mentions a limit of 20,000 work items, it seems like the number of open work items is much lower (around 6500 in the reported case). This suggests that the query being used to fetch work items might not be properly filtering by project or state. It's possible that the query is retrieving all work items, including those that are closed, completed, or removed, which then exceeds the limit.

This inefficient querying is a major contributing factor to the bug. If the integration could intelligently filter out irrelevant work items, the size limit might not be an issue in the first place.

Request

To improve the Azure DevOps integration, here are a few feature requests:

  1. Area Path Filtering: Allow users to filter the list of work items by area paths within the project. This would enable developers to focus on specific areas of the project they're responsible for.
  2. Prioritize Assigned Items: When showing all items, prioritize and display work items assigned to the current user at the top of the list. This would make it easier for developers to quickly find the tasks they need to work on.
  3. Improved Filtering and Search: Enhance the filtering and search capabilities to allow users to quickly find specific work items based on keywords, tags, or other criteria.

These enhancements would significantly improve the usability of the integration and make it easier to manage tasks in large Azure DevOps projects.

Error Details

Here's the raw error message from the Rider log file:

WARN - #c.i.t.i.TaskManagerImpl - Cannot connect to AZDWorkItemRepository(URL='https://dev.azure.com')
com.intellij.collaboration.api.HttpStatusErrorException: HTTP Request Request POST https://dev.azure.com/dfds/Velocity/_apis/wit/wiql?api-version=7.2-preview.2 failed with status code 400 and response body: {"$id":"1","innerException":null,"message":"VS402337: The number of work items returned exceeds the size limit of 20000. Change the query to return fewer items.","typeName":"Microsoft.TeamFoundation.WorkItemTracking.Server.WorkItemTrackingQueryResultSizeLimitExceededException, Microsoft.TeamFoundation.WorkItemTracking.Server","typeKey":"WorkItemTrackingQueryResultSizeLimitExceededException","errorCode":0,"eventId":3200}
	 at com.gafner.plugin.azd.api.q.a(SourceFile:49)
	 at com.gafner.plugin.azd.api.q.a(SourceFile:79)
	 at com.gafner.plugin.azd.api.q.a(SourceFile:98)
	 at com.gafner.plugin.azd.api.r.a(SourceFile:168)
	 at com.gafner.plugin.azd.api.r.b(SourceFile:167)
	 at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:684)
	 at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662)
	 at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2200)
	 at java.base/java.util.concurrent.CompletableFuture$MinimalStage.thenApply(CompletableFuture.java:2948)
	 at java.net.http/jdk.internal.net.http.ResponseSubscribers$MappingSubscriber.getBody(ResponseSubscribers.java:843)
	 at com.gafner.plugin.azd.api.v$a$a.invokeSuspend(SourceFile:146)
	 at com.gafner.plugin.azd.api.v$a$a.a(SourceFile)
	 at com.gafner.plugin.azd.api.v$a$a.invoke(SourceFile)
	 at com.gafner.plugin.azd.api.o.sendAndAwaitCancellable(SourceFile:95)
	 at com.gafner.plugin.azd.api.o$a.invokeSuspend(SourceFile)
	 at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	 at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	 at kotlinx.coroutines.internal.SoftLimitedDispatcher$Worker.run(SoftLimitedDispatcher.kt:130)
	 at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
	 at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:613)
	 at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:1183)
	 at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:778)
	 at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:765)

This error clearly indicates that the Azure DevOps API is imposing a limit of 20,000 work items. The integration needs to be smarter about how it fetches and displays work items to avoid this limit.

Environment Details

Here's the environment where this bug was observed:

  • Operating System: Windows 11
  • Plugin Version: 2025.2.50
  • JetBrains IDE: Rider
  • JetBrains IDE Version: 2025.2.3
  • Azure DevOps Type: Azure DevOps Services (cloud)
  • Service/Server URL: https://dev.azure.com/dfds

This information can be helpful for developers trying to reproduce the bug or identify potential compatibility issues.

Frequency

This bug happens consistently every time the conditions are met (project with more than 20,000 work items and "Include issues not assigned to me" option checked).

Potential Solutions

Here are some potential solutions to address this bug:

  • Implement Pagination: The most straightforward solution is to implement pagination, allowing users to browse through work items in smaller chunks. This would prevent the query from exceeding the size limit..
  • Optimize the Query: Improve the query to filter out irrelevant work items (e.g., closed, completed, or removed items). This would reduce the number of work items being returned..
  • Provide More Filtering Options: Allow users to filter work items by area path, assigned user, state, or other criteria. This would enable users to narrow down the list of work items to a manageable size.
  • Increase the Size Limit (If Possible): While not ideal, increasing the size limit on the Azure DevOps API side could provide a temporary workaround. However, this might impact performance and scalability.

By implementing one or more of these solutions, the Azure DevOps integration can be made more robust and usable for large projects.

Conclusion

The Azure DevOps integration bug related to the work item limit is a significant issue that impacts developers working on large projects. By understanding the bug, how to reproduce it, and potential solutions, we can work towards improving the integration and making it a more valuable tool for managing tasks in Azure DevOps. Let's hope the developers of the plugin address this issue soon!