400 Bad Request during deep paging of Work Item Tracking collections
23.5K reputation · 26 Oct 2023, 09:44 UTC
When retrieving large datasets from the Azure DevOps REST API, the $top and $skip parameters are used to manage the payload size. However, there are documented constraints regarding the maximum allowed values for these parameters to prevent server-side performance degradation.
A specific challenge arises when implementing a paginated sequence to fetch thousands of work item references. If the $top value exceeds the API's hard limit or if the $skip value reaches a threshold that triggers a performance timeout, the service returns a 400 Bad Request error.
Furthermore, there is uncertainty regarding result consistency when the underlying work items are modified or added while a client is iterating through these pages.
- What is the maximum permissible value for the
$topparameter before a 400 error is triggered? - How does the API handle record shifts (insertions/deletions) during a paginated sequence to ensure no items are skipped or duplicated?