Add ability to associate an ID with tasks

[imotov]

Adds support for capturing the X-Opaque-Id header from a REST request and storing it's value in the tasks that this request started. It works for all user-initiated tasks (not only search).

Closes #23250

Usage:

$ curl -H "X-Opaque-Id: imotov" -H "foo:bar" "localhost:9200/_tasks?pretty&group_by=parents"
{
  "tasks" : {
    "7qrTVbiDQKiZfubUP7DPkg:6998" : {
      "node" : "7qrTVbiDQKiZfubUP7DPkg",
      "id" : 6998,
      "type" : "transport",
      "action" : "cluster:monitor/tasks/lists",
      "start_time_in_millis" : 1513029940042,
      "running_time_in_nanos" : 266794,
      "cancellable" : false,
      "headers" : {
        "X-Opaque-Id" : "imotov"
      },
      "children" : [
        {
          "node" : "V-PuCjPhRp2ryuEsNw6V1g",
          "id" : 6088,
          "type" : "netty",
          "action" : "cluster:monitor/tasks/lists[n]",
          "start_time_in_millis" : 1513029940043,
          "running_time_in_nanos" : 67785,
          "cancellable" : false,
          "parent_task_id" : "7qrTVbiDQKiZfubUP7DPkg:6998",
          "headers" : {
            "X-Opaque-Id" : "imotov"
          }
        },
        {
          "node" : "7qrTVbiDQKiZfubUP7DPkg",
          "id" : 6999,
          "type" : "direct",
          "action" : "cluster:monitor/tasks/lists[n]",
          "start_time_in_millis" : 1513029940043,
          "running_time_in_nanos" : 98754,
          "cancellable" : false,
          "parent_task_id" : "7qrTVbiDQKiZfubUP7DPkg:6998",
          "headers" : {
            "X-Opaque-Id" : "imotov"
          }
        }
      ]
    }
  }
}

[mattweber]

+1

I could definitely use this feature!

[s1monw]

this looks reasonable @imotov lets make it reviewable ie. move it out of PoC mode and we take it from there?

[imotov]

Added pluggable headers, tests and documentation.

[s1monw]

@imotov I just saw this that you updated it. Sorry. I will do a review now but it needs a merge with master.

[s1monw]

this LGTM I left one question / suggestion

[s1monw]

even though we have http.max_header_size I wonder if we should also add a hard limit to the total size here. We can simply accumulate the size of the keys and values for this and fail hard if is exceeded. I really don't want to hold on to MB of strings here that are literally user input. It can be simply a derivative of http.max_header_size?

[imotov]

Makes sense! I am going to resolve conflicts and add this check.

[imotov]

@s1monw I merged in master, resolved conflicts and pushed check for the headers size.

[nik9000]

I feel like we iterate this Set a lot so we'd be better off making sure it isn't a HashSet which requires iteration of the buckets. Premature optimization, I know, but I'd feel comfortable if we copied it to a List here.

[imotov]

@s1monw do you want to take another look before I merge this in? Also should this be 7.0-only or should I try back-porting this to 6.x? What do you think?

[s1monw]

LGTM

[nik9000]

Also should this be 7.0-only or should I try back-porting this to 6.x? What do you think?

It is a little breaking for the plugin API but not very. I think it'd be fine to backport.

[Mpdreamz]

Super late to this but is there a particular reason for this being a request header and not a common query string parameter? I would personally much rather settle on the latter.

[imotov]

@Mpdreamz it was the most straightforward way to implement it internally across all requests in a transparent way. It also seems different in the nature to common request parameters, that change the output format. In our case we just mark the request, which is more similar to authentication or "run-as" headers then to the common format parameters.

[codebrain]

+1 to @Mpdreamz sentiment around this being preferred as a querystring parameter.

Implemented in the .NET client - https://github.com/elastic/elasticsearch-net/pull/3277/files

As far as I can see this parameter is only valid on certain user-initiated actions, yet the parameter value is set at the request headers level? In the .NET client this means that the value can theoretically be set on any API call - which may start to mislead client users. I can see the justification for the RunAs parameter, but this one does look different in scope.

Using the parameter in the headers collection as a filter to the task lists is also a little non-obvious and ought to be on the querystring call to tasks list, imo.

[imotov]

As far as I can see this parameter is only valid on certain user-initiated actions

I am not totally sure what you mean by this. Could you elaborate?

[codebrain]

As far as I can tell this parameter only makes sense on API calls where there are potentials for long running tasks? i.e. if a client set this parameter (unique id) on every API call, would every API call result in a task in the task management API?

[imotov]

As far as I can tell this parameter only makes sense on API calls where there are potentials for long running tasks?

That's the main use case, but nobody prevents you from using it on every call since sometimes it's not very clear how long a call will take and definition of "long" is somewhat vague.

if a client set this parameter (unique id) on every API call, would every API call result in a task in the task management API?

Every API call (including internal API calls) result in a task in the task manager regardless. Even if you perform a call to list tasks in the task manager you will see this call in the list of returned tasks.

[codebrain]

Thanks for clarifying @imotov