RFC-61: Evolving Search Capabilities: Addressing Scalability with a New, Enhanced Search API

Thanks for publishing the RFC.

I feel this particular change will have a significant impact for a number of partners. It will also seems likely to impact many customers who have written their own integrations with these API’s or similar scripts written by solution partners.

I think you should consider a potentially longer deprecation period with this in mind. Potentially it may also be worth giving admins the tools to understand whether they have any integrations or scripts using these API’s, or emailing customers that are using these endpoints. ie. a page showing which users are using the endpoints (or for a user, which API token is being used to call the endpoints)

To put in context I searched our Bitbucket for usages of the search endpoints and identified many different projects using these endpoints. Some of which are deployed in customer environments and very time consuming to change.

I want to dive specifically into the expression evaluate endpoint. The expression/eval endpoint was the only method where we determined it was possible to generate a report in a reasonable time frame on Jira work logs across realistically sized Jira projects (say > 10,000 issues with work logs). A key part of making this work in a reasonable time was making the requests in parallel.

From what you have mentioned, it seems from an app developer POV, the fastest way to load this information now is likely not to be the new expression endpoint, but:

  • collect all issue ID’s via /search/jql (100 at a time)
  • make parallel requests to the bulk fetch endpoint for those same issue ids and same fields we were previously requesting via the expression API.

This looks to me like it will be slower for the user (since waiting for the sequential search requests 100 at a time), and ultimately just as much of an impact on Atlassian infrastructure (bulk loading fields for 10k issues in parallel).

I have the feeling that these changes are ignoring the valid use case of wanting to return small amounts of data across many issues (10k, 100k, 1m) in a time frame where a user will not give up on the page.