Bulk Move/Edit issues with high number of custom fields can timeout on validations

 
Atlassian update - 01 July 2022

Hi everyone, 
 
Thank you for your patience while we were working on this issue.
 As per our analysis of the original issue, we had seen bulk issue move operation generally time out on page: “Step 3 - Update fields for <Issue-type> issues in the <project_name> project” (BulkMigrateSetFields!default.jspa). Hence, this page became the focus of this JAC for us.
We discovered that these time-outs were due to processing of high number of custom fields. A fix for that has been pushed out which seems to have resolved these page time outs for most of the impacted customers.

However, we do recognise that there might be some other reasons (besides high number of custom fields) or some other pages/operations at which page time outs could be seen for certain customers. The following new tickets have been created for this purpose:

• https://jira.atlassian.com/browse/JRACLOUD-79297
• https://jira.atlassian.com/browse/JRACLOUD-79298
• https://jira.atlassian.com/browse/JRACLOUD-79299

Please watch these issues in case your use-case is covered by these tickets. If not, we urge you to please reach out to us via our DoS queue and help us understand your use-case and root-cause better. Accordingly, we will be able to assess the situation and provide further fixes.
For now, we are closing this issue which is specific to "Step 3" of bulk issue move as called out above.
 
Thanks,
Shobhna Raj
Developer, Issue Bulk Updates, Jira Platform 

Issue Summary

Upon investigation of a performance case, we figured out with our developers that a combination of high number of the following elements can impact on page load throughout the bulk operation process potentially leading even to timeouts depending on the request time:

• Number of custom fields
• Number of issues
• Number of issue types
• Number of projects

Steps to Reproduce

(sample reproduction scenario looks like this)

1. Create 60 custom fields
2. Create 1000 issues (max limit for bulk move issues selection)
3. Bulk move 1000 issues from one project to another

The response time of page load for one destination project issue type page(in step 3 of bulk move), depends on the product of number of issues selected for that particular destination project issue type and the average number of custom fields present in those issues(issues selected can be of different source project and issue types with a varying number of custom fields).

As the timeout for the proxy to return the response of page load is 60s (and if assumed on average one method call takes 1ms), so in order to cross the 60s timeout, we require 60 custom fields(average) with 1000 issues (Max limit for issues selection in bulk move) and this is just for one of the method calls, if we also consider the execution time of other methods this will definitely cross the timeout threshold.

The number of issues and custom fields mentioned are for worst case scenario, in actual, there can be a case where the timeout can even occur for 40s calculated time(due to addition of other methods execution time) and for issues count lesser than 1000 with a high number of custom fields (500). More information on other methods taking more execution time can be found on this page

The Number of project and issue types adds to the slowness of bulk move operation, as the number of page loads in step 3 of bulk move depends on the number of distinct destination project and issue types selection. eg. In a bulk move process, if the user has selected 15~20 different target projects and issue types combinations, they have to go through 15~20 screens of field and workflow mappings for the selected targets, which takes the bulk move experience more time to go through and complete.

Expected Results

Bulk operation should be loaded as usual without page timeouts.

Actual Results

Bulk operation is slow and eventually times out.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available