-
Bug
-
Resolution: Not a bug
-
High
-
None
-
Severity 3 - Minor
-
Hi everyone,
Let me shed some light behind this issue.
I confirm that the change of maxResults value for search API was intentional and it’s not a bug. We decided to reduce the maxResults value not only due to increased performance and memory impact on Jira but also after observing the volume of REST API requests that were unfinished because of timeout errors. Whilst we appreciate that the solution may not be ideal to the problem, and we keep investing into improving the performance of Jira searches, it was necessary to reduce the number of failed API requests without further delay.
According to Atlassian REST API policy default and maximum sizes of paged data are not considered part of the API and may change without deprecation notice. But I completely understand the impact this change caused to REST API clients that relied on the anticipated value of 1000 results and I apologize for lack of prior communication.
In principle, our recommended solution is to rely on pagination to retrieve the desired number of results in chunks for any API that supports startAt parameter. We also recommend that REST API clients systematically confirm maxResults value when making the requests to prevent disruptions whenever these limits change. That being said, we updated the related Knowledge Base article, which was inaccurately suggesting the default value of response results to be 1000.
Regarding the problems for startAt offset above 1000 in combination with expanded changelog, we need to investigate them as separate issue (see JRACLOUD-67458).
Thank you for your understanding.
Eve Stankiewicz
Jira Cloud Product Management
Summary
JIRA Cloud REST API /rest/api/latest/search?maxResults=1000 is returning only 100 results.
Steps to Reproduce
- Call to a REST API with maxResults = 1000
Expected Results
The API returns all issues until 1000 results.
Actual Results
The API returns only 100 results.
Notes:
This is impacting add-on dashboards and reporting.
Changing maxResults Parameter for JIRA REST API.
Workaround
You can use the startAt parameter to get the other results (if more than 100 are returned). /search endpoint implements pagination api which can be used to retrieve all the required data
- duplicates
-
JSWCLOUD-16236 Jira Cloud API search method maxResults error BUGGGGGG!!!
- Closed
- is related to
-
- Gathering Interest
- is caused by
-
ADDON-230 Failed to load
-
CRANE-1177 Failed to load
- relates to
-
HOT-80655 Loading...
-
[JRACLOUD-67570] JIRA Cloud REST API /rest/api/latest/search?maxResults=1000 is returning only 100 results.
This is a difficult limitation for our system, which is built on top of Jira systems. The given limitation and reasons are not acceptable. Please consider increasing the limits, or at the very least provide an offset parameter to the API so multiple calls can be a workaround.
| Remote Link | Original: This issue links to "JCE-1177 (Ecosystem JIRA)" [ 321627 ] | New: This issue links to "CRANE-1177 (Ecosystem JIRA)" [ 321627 ] |
| Remote Link | New: This issue links to "Page (Confluence)" [ 508922 ] |
I am really sorry that I migrate from server to cloud. Now it's hard to return. This is not acceptable.
Jira has tons of basic cloud software issues that other cloud software are offering in the market. THIS IS REALLY VERY BAD APPROACH FROM JIRA
| Workflow | Original: JIRA Bug Workflow w Kanban v6 - Restricted [ 2438846 ] | New: JAC Bug Workflow v3 [ 3358927 ] |
I understand your point and I agree it would be much more comfortable being able to export everything in a shot. On the other hand I have to agree with the developers that it is very difficult to determine the average amount of data each issue may contain and, since we have seen cases in the past of people literally DoSsing their instances by trying to retrieve way too many issues at the same time, they decided to set some kind of 'safe' limit.
For more details on this, see:
- https://ecosystem.atlassian.net/browse/DEVHELP-1027
- https://ecosystem.atlassian.net/browse/ADDON-230
Finally, there is actually an open Feature Request to have the limit increased that has been created more than one year ago but that got only one vote so far:
I have linked the feature request to this ticket so that maybe more people will be aware of it and will vote for it, giving it a chance to get back on the developers' table at some point in time.
| Link | New: This issue is related to JRACLOUD-67722 [ JRACLOUD-67722 ] |
Kael Hammond
added a comment - Incorrect behavior attributed to an "optional" parameter is just making excuses. Policy that allows you to avoid fixing a product people have paid for is just an excuse with paper work.
Kael Hammond
added a comment - Incorrect behavior attributed to an "optional" parameter is just making excuses. Policy that allows you to avoid fixing a product people have paid for is just an excuse with paper work.
Not that pagination and "start-at" mechanisms are inherently broken.... Assume we have items sequentially numbered 1 thru 5000... Pagination is set to 25 items..
So expectation:
first call: 1 thru 25
second call 26 thru 50
BUT if the collection changes between the calls
Say #3 is deleted after the first call.. Then "skipping 25" would result in 27 thru 51 being returned and #26 never beeng seen.
ATOMIC results require the use of some persistent (Atlassian server side) snapshot to ensure that all of the (potentially hundereds of sequential reqests) all are related to the data as it exists at a single point in time.