Hi everyone!
I am glad to announce that there is another experimental endpoint in properties bulk update API. It allows you to update several entity properties in multiple issues with one call.
You can find more informations in docs here: Issues properties bulk update
If you have any questions or requests, we will be happy to address them.
I’m using the bulk property update API to store the children of each Epic as a property on each Epic.
This is essentially an array of issues attached to the “children” property.
This works for most Epics, but when an Epic has lots of child issues, and those issues have lots of sub-task children, I begin to get a status 400, and no update occurs.
This only happens for the 2 largest Epics in my instance, but I’m concerned many of my customers may not see the children of their Epics if they are over the limit.
Is there some kind of limit on how big an array can be when it’s saved as a property?
Best Regards,
Rhys
Hi @RhysDiab!
There actually is a limit on how big of a property you can create. In documentation there is specified limit on length of property values, which is 32768 bytes.
If value is bigger than that, property will not be created, which should be the same for all endpoints that let you create or update them.
You can find more informations about properties here: entity property docs.
Probably the length of JSON generated from array of issues exceeds this limit for these few larger epics and request fails.
I hope this answers you question. If you have any further questions, let me know.
Best regards,
Krzysztof Kościuk
Thanks for the insight @KrzysztofKosciuk!
Looks like it’s not specific to the issue properties bulk update API.
Thanks again.
Rhys
I am trying to use the API endpoint for updating issue properties. I found a problem with using the new endpoint. In my scenario I am trying to the same property for many issues in separate requests.
Example:
1st request:
/rest/api/3/issue/properties
{
"entitiesIds": [
374484
],
"properties": {
"foobar.magic": {
"TEST": 123,
"TEST2": "456"
},
"foobar.magic2": {
"TEST": 123,
"TEST2": "456"
}
}
}
2nd request:
{
"entitiesIds": [
374485
],
"properties": {
"foobar.magic": {
"TEST": 123,
"TEST2": "456"
},
"foobar.magic2": {
"TEST": 123,
"TEST2": "456"
}
}
}
3rd request:
{
"entitiesIds": [
374486
],
"properties": {
"foobar.magic": {
"TEST": 123,
"TEST2": "456"
},
"foobar.magic2": {
"TEST": 123,
"TEST2": "456"
}
}
}
Second and third request might fail due the below error:
{“errorMessages”:[“The task was rejected, most likely because another bulk update of the same property is running. Try again later.”],“errors”:{}}
when the first one isn’t in COMPLETE state, although they update different entities.
I think the task shouldn’t be rejected in case it updates different entity.
Regards
Andrzej
Hi @awieczorek
This is indeed how this API works in the moment. It can run one bulk entities update at once, no matter on which entities.
I see that the error message is wrong, which will be fixed. For now I could only suggest to try to do such an update in one request.
We will do our best to make it so in the next version of this API it will be possible to bulk update different entities at once.
Best regards,
Krzysztof Kościuk
Thanks - if you can implement that change we estimate we’ll be able to reduce the number of requests we make to the issue properties endpoint by at least 50% which equates to around 250,000 requests per 24hrs.
We’d also greatly benefit from being able to update different sets of issues with different property values in parallel. Right now, we always have to wait for the previous task to finish, polling the get-task API to know when we can proceed with the next call.
I’d also like to be able to update different issues at the same time in parallel.
Is it recommended to use the set issue property endpoint if I want to update different issues in parallel but not in the same request?