| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278 | [[tasks]]== Task Management APIbeta[The Task Management API is new and should still be considered a beta feature.  The API may change in ways that are not backwards compatible][float]=== Current Tasks InformationThe task management API allows to retrieve information about the tasks currentlyexecuting on one or more nodes in the cluster.[source,js]--------------------------------------------------GET _tasks <1>GET _tasks?nodes=nodeId1,nodeId2 <2>GET _tasks?nodes=nodeId1,nodeId2&actions=cluster:* <3>--------------------------------------------------// CONSOLE// TEST[skip:No tasks to retrieve]<1> Retrieves all tasks currently running on all nodes in the cluster.<2> Retrieves all tasks running on nodes `nodeId1` and `nodeId2`.  See <<cluster-nodes>> for more info about how to select individual nodes.<3> Retrieves all cluster-related tasks running on nodes `nodeId1` and `nodeId2`.The result will look similar to the following:[source,js]--------------------------------------------------{  "nodes" : {    "oTUltX4IQMOUUVeiohTt8A" : {      "name" : "H5dfFeA",      "transport_address" : "127.0.0.1:9300",      "host" : "127.0.0.1",      "ip" : "127.0.0.1:9300",      "tasks" : {        "oTUltX4IQMOUUVeiohTt8A:124" : {          "node" : "oTUltX4IQMOUUVeiohTt8A",          "id" : 124,          "type" : "direct",          "action" : "cluster:monitor/tasks/lists[n]",          "start_time_in_millis" : 1458585884904,          "running_time_in_nanos" : 47402,          "cancellable" : false,          "parent_task_id" : "oTUltX4IQMOUUVeiohTt8A:123"        },        "oTUltX4IQMOUUVeiohTt8A:123" : {          "node" : "oTUltX4IQMOUUVeiohTt8A",          "id" : 123,          "type" : "transport",          "action" : "cluster:monitor/tasks/lists",          "start_time_in_millis" : 1458585884904,          "running_time_in_nanos" : 236042,          "cancellable" : false        }      }    }  }}--------------------------------------------------// TESTRESPONSEIt is also possible to retrieve information for a particular task. The following example retrieves information about task `oTUltX4IQMOUUVeiohTt8A:124`:[source,js]--------------------------------------------------GET _tasks/oTUltX4IQMOUUVeiohTt8A:124--------------------------------------------------// CONSOLE// TEST[catch:missing]If the task isn't found, the API returns a 404.To retrieve all children of a particular task:[source,js]--------------------------------------------------GET _tasks?parent_task_id=oTUltX4IQMOUUVeiohTt8A:123--------------------------------------------------// CONSOLEIf the parent isn't found, the API does not return a 404.You can also use the `detailed` request parameter to get more information aboutthe running tasks. This is useful for telling one task from another but is morecostly to execute. For example, fetching all searches using the `detailed`request parameter:[source,js]--------------------------------------------------GET _tasks?actions=*search&detailed--------------------------------------------------// CONSOLE// TEST[skip:No tasks to retrieve]The results might look like:[source,js]--------------------------------------------------{  "nodes" : {    "oTUltX4IQMOUUVeiohTt8A" : {      "name" : "H5dfFeA",      "transport_address" : "127.0.0.1:9300",      "host" : "127.0.0.1",      "ip" : "127.0.0.1:9300",      "tasks" : {        "oTUltX4IQMOUUVeiohTt8A:464" : {          "node" : "oTUltX4IQMOUUVeiohTt8A",          "id" : 464,          "type" : "transport",          "action" : "indices:data/read/search",          "description" : "indices[test], types[test], search_type[QUERY_THEN_FETCH], source[{\"query\":...}]",          "start_time_in_millis" : 1483478610008,          "running_time_in_nanos" : 13991383,          "cancellable" : true        }      }    }  }}--------------------------------------------------// TESTRESPONSEThe new `description` field contains human readable text that identifies theparticular request that the task is performing such as identifying the searchrequest being performed by a search task like the example above. Other kinds oftask have different descriptions, like <<docs-reindex,`_reindex`>> whichhas the search and the destination, or <<docs-bulk,`_bulk`>> which just has thenumber of requests and the destination indices. Many requests will only have anempty description because more detailed information about the request is noteasily available or particularly helpful in identifying the request.[IMPORTANT]==============================`_tasks` requests with `detailed` may also return a `status`. This is a reportof the internal status of the task. As such its format varies from task to task.While we try to keep the `status` for a particular task consistent from versionto version this isn't always possible because we sometimes change theimplementation. In that case we might remove fields from the `status` for aparticular request so any parsing you do of the status might break in minorreleases.==============================The task API can also be used to wait for completion of a particular task. Thefollowing call will block for 10 seconds or until the task with id`oTUltX4IQMOUUVeiohTt8A:12345` is completed.[source,js]--------------------------------------------------GET _tasks/oTUltX4IQMOUUVeiohTt8A:12345?wait_for_completion=true&timeout=10s--------------------------------------------------// CONSOLE// TEST[catch:missing]You can also wait for all tasks for certain action types to finish. Thiscommand will wait for all `reindex` tasks to finish:[source,js]--------------------------------------------------GET _tasks?actions=*reindex&wait_for_completion=true&timeout=10s--------------------------------------------------// CONSOLETasks can be also listed using _cat version of the list tasks command, whichaccepts the same arguments as the standard list tasks command.[source,js]--------------------------------------------------GET _cat/tasksGET _cat/tasks?detailed--------------------------------------------------// CONSOLE[float][[task-cancellation]]=== Task CancellationIf a long-running task supports cancellation, it can be cancelled with the cancel tasks API. The following example cancels task `oTUltX4IQMOUUVeiohTt8A:12345`:[source,js]--------------------------------------------------POST _tasks/oTUltX4IQMOUUVeiohTt8A:12345/_cancel--------------------------------------------------// CONSOLEThe task cancellation command supports the same task selection parameters as the list tasks command, so multiple taskscan be cancelled at the same time. For example, the following command will cancel all reindex tasks running on thenodes `nodeId1` and `nodeId2`.[source,js]--------------------------------------------------POST _tasks/_cancel?nodes=nodeId1,nodeId2&actions=*reindex--------------------------------------------------// CONSOLE[float]=== Task GroupingThe task lists returned by task API commands can be grouped either by nodes (default) or by parent tasks using the `group_by` parameter.The following command will change the grouping to parent tasks:[source,js]--------------------------------------------------GET _tasks?group_by=parents--------------------------------------------------// CONSOLEThe grouping can be disabled by specifying `none` as a `group_by` parameter:[source,js]--------------------------------------------------GET _tasks?group_by=none--------------------------------------------------// CONSOLE[float]=== Identifying running tasksThe `X-Opaque-Id` header, when provided on the HTTP request header, is going to be returned as a header in the response as well asin the `headers` field for in the task information. This allows to track certain calls, or associate certain tasks witha the client that started them:[source,sh]--------------------------------------------------curl -i -H "X-Opaque-Id: 123456" "http://localhost:9200/_tasks?group_by=parents"--------------------------------------------------//NOTCONSOLEThe result will look similar to the following:[source,js]--------------------------------------------------HTTP/1.1 200 OKX-Opaque-Id: 123456 <1>content-type: application/json; charset=UTF-8content-length: 831{  "tasks" : {    "u5lcZHqcQhu-rUoFaqDphA:45" : {      "node" : "u5lcZHqcQhu-rUoFaqDphA",      "id" : 45,      "type" : "transport",      "action" : "cluster:monitor/tasks/lists",      "start_time_in_millis" : 1513823752749,      "running_time_in_nanos" : 293139,      "cancellable" : false,      "headers" : {        "X-Opaque-Id" : "123456" <2>      },      "children" : [        {          "node" : "u5lcZHqcQhu-rUoFaqDphA",          "id" : 46,          "type" : "direct",          "action" : "cluster:monitor/tasks/lists[n]",          "start_time_in_millis" : 1513823752750,          "running_time_in_nanos" : 92133,          "cancellable" : false,          "parent_task_id" : "u5lcZHqcQhu-rUoFaqDphA:45",          "headers" : {            "X-Opaque-Id" : "123456" <3>          }        }      ]    }  }}--------------------------------------------------//NOTCONSOLE<1> id as a part of the response header<2> id for the tasks that was initiated by the REST request<3> the child task of the task initiated by the REST request
 |