Thanks everyone for sharing your valuable feedback. A quick update on how we are tracking for this change - we want to ensure a smooth transition for our customers, so based on customer feedback so far, we will be pausing the transformation of existing issues that are over the limit.
We will begin the rollout for enforcement of per issue limits for list fields in the last week of March 2024, but all existing issues over the limit will be retained as is. We will provide additional 3 months notice before any transformations are rolled out.
Thank you in advance for your understanding and support as we work to provide you with better and more reliable experiences on Jira. If you have any concerns or feedback, please comment in the section below. We’d love to hear how we can help you!
Please can you confirm how this will affect the GET requests?
i.e. for GET rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/comment
If an issue previously had 5000+ comments, after the deprecation will the API simply stop returning values after it has reached 5000 comments? Will the response still be 200 OK once it has returned the maximum number of comments?
If the issue data already exceeds the limits, it will be converted into an attachment within the issue. If an issue previously had 5000+ comments, the GET API will return a maximum of 5000 comments with a 200 OK response, and the additional comments will be transformed into an attachment within the issue.
I have a question about “Existing issues over the limit” regarding Issue links. Could you share more details about what data and format the attachment will contain and how the transformation rule will decide which issue links should be removed?
Hi Marcin,
We’re still to finalise details but this is the current expected experience:
The oldest Issue links will be removed - this is selected based on issue links with the lowest id.
The attachment will be in a csv format. Each row will contain
If issue data already exceeds the limits, this will be transformed into an attachment within the issue.
Just my 2 cent here, but that’s sounds not like the best decision to handle these situations.
From an administrative point-of-view we would all agree that issues that have more than the listed entities are not the best idea, but there are always reasons for that!
Comments: 5000 comments per issue
Worklogs: 5000 worklogs per issue
Attachments: 2000 attachments per issue
Issue links: 2000 issue links per issue (excluding child issues and subtasks)
Remote links: 2000 remote issue links per issue
5000 worklogs per issues? That’s normal if customers heavily using Tempo Planner / Timesheet, basically every Atlassian Partner.
Personally, this was never an issue on-premise. The problem here is the whole architecture and asynchronous loading of everything that makes a bad UX for end-users.
I’ll remember a migration where a few issues had > 1000 issue links because of cloning and using it as a template issue. Loading this on-premise wasn’t an issue. Loading it on Cloud was reported as an issue in the first hours after migration. It took ages to load the issue. We ended up running some scripts to remove all issue links to mitigate the situation.
So yes, you can add more and more limits to keep a certain performance in the front-end but the root-cause might the current architecture that itself. Atlassian want to have the all these huge on-premises migrated to the Cloud, Cloud should be able to handle the data without noticeable differences.
Apologies for the late response, and thank you for your valuable feedback!
In our efforts to minimize the impact on our users, we carefully considered extensive data points regarding the existing usage of each entity. The per-issue limits mentioned above cover P99.999 of all existing issue data, including usage from Atlassian partner apps.
However, I acknowledge and agree that there are further improvements to be made in order to ensure a good user experience for end-users. We continuously review and iterate on enhancements to improve the performance and reliability of Jira Cloud.
Please feel free to schedule some time on my calendar if you would like to discuss additional details or concerns. https://calendar.app.google/SbGak9xn55Ld3Tpe8
Hi, everyone! We have taken the new Get Issue Limit Report API and built a beautiful dashboard report showing issues that are approaching or exceeding these new limits:
