Allow GET /_tasks/<taskid> to support a list of tasks

[joshuar]

Describe the feature:

It would be cool if GET /_tasks/<taskid> could support a list of task ids (i.e., comma separated or as a request body).

My use case here is to avoid using the detailed parameter together with the actions parameter, which may cause detailed information to be gathered for quite a few running tasks, which according to the docs can be expensive. So I'd like to target the detailed usage to just a specific subset of tasks. Rather than issuing a request per tasks, I'd like to issue a single request with a list of tasks.

[jasontedor]

I would prefer that we stop adding these APIs that allow GET on a comma-separated list of resources. The problem that I have with them is that it complicates the API:

• what status do we return if some but not all of the tasks are missing?
• what status do we return if some but not all of the tasks cause an internal server error?
• what status do we return if some of the tasks are present, some are missing, and some cause an internal server error?

I have my take on this, but we have endlessly debated questions like this before and I don't think anyone is satisfied with the answers. I especially think that clients are unhappy no matter what we choose. Regardless of how we answer them, it also means that we have to have complicated responses to accommodate for these partial failure scenarios with a response body to account for errors and the details of such, and response for the tasks that exist. We end up with a ball of complicated code and a complicated API for a little convenience all to save multiple roundtrips. To me that tradeoff is not worth it and I would like us to go in the direction of simplicity here.

[elasticmachine]

Pinging @elastic/es-distributed

[bleskes]

Another complication here is that that specific API is currently geared towards a single task. If we want to return multiple tasks, we'll need to change the response format to be keyed by task id, which also means a BWC break. Not sure if it's worth it here.

@joshuar can you share more about what you're building? it sounds like you'd need a kind of pagination on the _tasks API?

[joshuar]

I was mainly just trying to avoid an expensive call to this API by specifying detailed. My interpretation of the docs is that this could make the call expensive.

My main goal was a Watch that checked this API and reported on any long running tasks, where a task was running for longer than a given threshold. For example for checking on long running searches I was intending on:

1. Hitting GET /_tasks?actions=*search
2. Filtering out any which are below the threshold based on running time.
3. Hit GET /_tasks/<taskid>?detailed where <taskid> was a list of tasks.
4. Act on the detailed task info.

Doing this on a regular interval, I wanted to minimise getting detailed task information.

[imotov]

@joshuar we recently added an ability to mark task groups using X-Opaque-Id header. We don't have an ability to filter by this header yet, but if we implemented that, would it work better for you? What problem are you trying to solve by this feature?

[joshuar]

Oh nice @imotov. Filtering by that would be ideal.

I was mainly just trying to follow what I interpreted as best practice for this API, which is to avoid using detailed where the number of tasks returned might be very large. Do we know how use of this parameter scales with regards to affecting performance? For example, doing GET /_tasks?actions=*search&detailed where there might be 100 executing searches? 1000 searches?

Side note: we could/should update our best practices to recommend setting this header on requests? Seems extremely useful?

[imotov]

@joshuar I opened #30868. For some reason I thought it was already implemented, but it looks like I never got to it after all. Should we close this issue in favor of #30868?

[imotov]

Closing in favor of #30868