Throttle Limit and Error Handling about vsts-rest-api-specs HOT 4 CLOSED

• How many work items can I update with one PATCH request? 200.
• What makes this better than asynchronously sending single PATCH request to update single work item one by one? As answered above by @arievs, this makes it more performant, since the round trip to database are reduced.
• What is the recommended way of error handling when one or some of the operations in the batch update PATCH request failed (error code: 400, 307, etc.)? So you will get the error code: 500 for all the requests that have failed. You will have to parse it accordingly.

If you have 3 work items to be updated in your batch update call and if the first work item fails to update, then updates for the work items after that will fail.

Refer the section entitled "case where single request in batch api fails" in Work Item Batch Update API Doc

Thanks
Nilesh Agrawal
Software Engineer
Microsoft VSTS - Agile

from vsts-rest-api-specs.

Hello,

Thank for posting the question.

Batch update should definitely be better from performance perspective.
Can you please share some more information about the way you are running this request? What error exactly you are getting? How many fields you are updating? How large is your payload?

Thanks,
Artur Ievsieiev
Software Engineer
Microsoft VSTS - Agile

from vsts-rest-api-specs.

Thanks for your reply.

I only attempted PATCH requests with 3~5 work items. There is currently no error yet. But I want to maximize what the VSTS API can provide for me.

Actually I want to use throttle here to maximize the performance of my application. The size limit of the JSON determines how many work items one can send per PATCH request; how many work items one can send at one time determines the payload my application should deal with at one time (in my case, how many messages should I fetch and process from the corresponding service bus).

Right now my application would only update owners (GPM/GEM/PM/EM) of VSTS work items. The amount of operations involved are no more than 4 (usually 1) per VSTS work item.

By "error handling", what worries me most are situations similar with this: if I send 100 VSTS work item in one JSON file in one PATCH request (if the API is capable of handing that many) (to the BATCH update VSTS API), with 1 failed due to some reason. (According to the doc, the whole JSON would be sent back as responses), how should I parse and locate the error efficiently?

from vsts-rest-api-specs.

A little more background about my application:
My application will [For 1 team project][with help of Service Bus - Topic, Azure Storage - Table]

1. process all VSTS work items that are both newly created and newly updated with areaPath;
2. fetch owners according to the areaPath from the Azure Storage - Table;
3. update with fields of owners in batch via VSTS batch update API.
   It is the last step that generated my current concern.

Till now, I do not know how many work items are created and updated with areaPath per day.

from vsts-rest-api-specs.