Search API Delayed Results vs Users API
There seems to be a substantial delay in the Search API vs the Users API when querying the same data, in the case that I've found, the tickets that are assigned to a specific user.
For example, if I create a new ticket in the system, assign it to a user and use the User API to request tickets assigned to that user with the following query:
users/(some user id)/tickets/assigned?sort_by=updated_at&sort_order=desc
I will immediately see the new ticket that I just created in the API response, which is exactly what I expect to happen.
However, if I use the Search API to request the tickets assigned to a user using the following query:
search.json?include=tickets(users)&query=type:ticket,status:open,sort:updated,order_by:desc,assignee:(some user id)
There will be a significant delay in between when I created the new ticket, and when I actually see it in the Search API response. In my experience it takes several minutes to finally be returned in the response.
I've found that the Search API is very useful for combining datasets and simplifies complex API requests, however the delay mentioned above is an issue for our application.
My questions are:
- Is this expected API behavior / is it a known issue?
- If so, can we expect any updates in the near term that will remove or reduce this delay?
- Since obtaining the most recent tickets assigned to a user may require multiple API calls (with the method above). Are there any other alternative or suggested solutions for obtaining the most up-to-date tickets assigned to a user without a significant delay? Using a single API request is preferable.
-
Hi Chuck P
Please keep in mind what happens when you save a change to a user: First, the actual user record is saved, and then, the changed user record is submitted to the federated fulltext search. This works much like other federated searches; it is not real time, but usually pretty quick. Excuse the soft time frames - the execution speed depends not only on your activity, but may encompass the loads of all of your pod's instances.
You see the same behaviour if you change a Light Agent to become a "real" Agent, and then try to assign tickets to him: You will also need to wait a few ... minutes, I'd say, so, the behaviour you see is both explainable and to be expected.
To your questions:- The API behaves as is to be expected.
- This is an architecture-inherent property and cannot be changed lightly.
- Is there a quicker way? Not without a bit of tweaking:
If you use the user endpoint and side-load the user's tickets, this may be more up to date - but I can't say for sure.
-
Hi Chuck! Delays in querying via the Search APIs are expected, up to a couple of minutes, as we note here. The underlying reasons are due to the nature of search...all data must first be indexed before it can become searchable. In addition to the time it takes to index the data, we also have multiple hosts that will be utilized (I believe that we may have up to three hosts, but don't quote this as canon), so if your request is routed through a host that has not yet been indexed, it can be delayed further. So generally speaking, indexing can take about a minute, but with the possibility of additional hosts, it can take a couple of minutes.
Please note that the teams that own the search functionality are constantly looking for ways to improve the service, so what is true today may not be true in the future. However, search indexing delays are an inevitability of how search works in general at this time.
With respect to other options Peter is correct that side-loading is the place that we would look for a solution, although we do not have a side-load available for what you are looking for. We always appreciate a developer trying to reduce the number of API calls, so thank you for taking the time to research this! When I was looking at the first API call that you noted, this looks to be an efficient way to get the most recently updated tickets assigned to a user. Just so that I understand and can see if there are other solutions, what situations would you need to make multiple API calls for with this request? -
Thanks for your responses, this gives me a better idea of what is and isn't possible with search API.
We've tested the user API as an alternative way to fetch assigned ticket data without the indexing delays that were mentioned, so we know this method works.
What was nice about the search API is that we were able to fetch relevant data pertaining to a ticket all at once. However, I think our current problem is that we would like a way to be able fetch a user's assigned tickets and include/side-load user identity data as well (eg requestor's primary email, and phone number).
My initial thinking is that we would first have to fetch all of the user's assigned tickets, then process an API request for user identities for each ticket.
Please correct me if I'm wrong, but it seems that this isn't currently possible with a single API request (search API, users API, or ticketing API)?
If you have any other suggestions, we are open to any other ideas you might have.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
3 Kommentare