[Docs] Add description for missing fields in Reindex/Update/Delete By Query (#26618)

This commit adds some missing description for some fields
in the Reindex/UBQ/DBQ responses.

docs/reference/docs/delete-by-query.asciidoc

@@ -212,6 +212,7 @@ The JSON response looks like this:
 {
   "took" : 147,
   "timed_out": false,
+  "total": 119,
   "deleted": 119,
   "batches": 1,
   "version_conflicts": 0,
@@ -223,7 +224,6 @@ The JSON response looks like this:
   "throttled_millis": 0,
   "requests_per_second": -1.0,
   "throttled_until_millis": 0,
-  "total": 119,
   "failures" : [ ]
 }
 --------------------------------------------------
@@ -233,6 +233,15 @@ The JSON response looks like this:
 
 The number of milliseconds from start to end of the whole operation.
 
+`timed_out`::
+
+This flag is set to `true` if any of the requests executed during the
+delete by query execution has timed out.
+
+`total`::
+
+The number of documents that were successfully processed.
+
 `deleted`::
 
 The number of documents that were successfully deleted.
@@ -245,14 +254,32 @@ The number of scroll responses pulled back by the delete by query.
 
 The number of version conflicts that the delete by query hit.
 
+`noops`::
+
+This field is always equal to zero for delete by query. It only exists
+so that delete by query, update by query and reindex APIs return responses
+ with the same structure.
+
 `retries`::
 
-The number of retries that the delete by query did in response to a full queue.
+The number of retries attempted by delete by query. `bulk` is the number
+of bulk actions retried and `search` is the number of search actions retried.
 
 `throttled_millis`::
 
 Number of milliseconds the request slept to conform to `requests_per_second`.
 
+`requests_per_second`::
+
+The number of requests per second effectively executed during the delete by query.
+
+`throttled_until_millis`::
+
+This field should always be equal to zero in a delete by query response. It only
+has meaning when using the <<docs-delete-by-query-task-api, Task API>>, where it
+indicates the next time (in milliseconds since epoch) a throttled request will be
+executed again in order to conform to `requests_per_second`.
+
 `failures`::
 
 Array of all indexing failures. If this is non-empty then the request aborted

docs/reference/docs/reindex.asciidoc

@@ -585,7 +585,7 @@ The JSON response looks like this:
   "timed_out": false,
   "total": 5,
   "updated": 0,
-  "created": 123,
+  "created": 5,
   "deleted": 0,
   "batches": 1,
   "noops": 0,
@@ -606,6 +606,15 @@ The JSON response looks like this:
 
 The number of milliseconds from start to end of the whole operation.
 
+`timed_out`::
+
+This flag is set to `true` if any of the requests executed during the
+reindex has timed out.
+
+`total`::
+
+The number of documents that were successfully processed.
+
 `updated`::
 
 The number of documents that were successfully updated.
@@ -614,10 +623,19 @@ The number of documents that were successfully updated.
 
 The number of documents that were successfully created.
 
+`deleted`::
+
+The number of documents that were successfully deleted.
+
 `batches`::
 
 The number of scroll responses pulled back by the reindex.
 
+`noops`::
+
+The number of documents that were ignored because the script used for
+the reindex returned a `noop` value for `ctx.op`.
+
 `version_conflicts`::
 
 The number of version conflicts that reindex hit.
@@ -631,6 +649,17 @@ actions retried and `search` is the number of search actions retried.
 
 Number of milliseconds the request slept to conform to `requests_per_second`.
 
+`requests_per_second`::
+
+The number of requests per second effectively executed during the reindex.
+
+`throttled_until_millis`::
+
+This field should always be equal to zero in a delete by query response. It only
+has meaning when using the <<docs-reindex-task-api, Task API>>, where it
+indicates the next time (in milliseconds since epoch) a throttled request will be
+executed again in order to conform to `requests_per_second`.
+
 `failures`::
 
 Array of all indexing failures. If this is non-empty then the request aborted

docs/reference/docs/update-by-query.asciidoc

@@ -262,6 +262,7 @@ The JSON response looks like this:
 {
   "took" : 147,
   "timed_out": false,
+  "total": 5,
   "updated": 5,
   "deleted": 0,
   "batches": 1,
@@ -274,7 +275,6 @@ The JSON response looks like this:
   "throttled_millis": 0,
   "requests_per_second": -1.0,
   "throttled_until_millis": 0,
-  "total": 5,
   "failures" : [ ]
 }
 --------------------------------------------------
@@ -284,10 +284,23 @@ The JSON response looks like this:
 
 The number of milliseconds from start to end of the whole operation.
 
+`timed_out`::
+
+This flag is set to `true` if any of the requests executed during the
+update by query execution has timed out.
+
+`total`::
+
+The number of documents that were successfully processed.
+
 `updated`::
 
 The number of documents that were successfully updated.
 
+`deleted`::
+
+The number of documents that were successfully deleted.
+
 `batches`::
 
 The number of scroll responses pulled back by the update by query.
@@ -296,6 +309,11 @@ The number of scroll responses pulled back by the update by query.
 
 The number of version conflicts that the update by query hit.
 
+`noops`::
+
+The number of documents that were ignored because the script used for
+the update by query returned a `noop` value for `ctx.op`.
+
 `retries`::
 
 The number of retries attempted by update-by-query. `bulk` is the number of bulk
@@ -305,6 +323,17 @@ actions retried and `search` is the number of search actions retried.
 
 Number of milliseconds the request slept to conform to `requests_per_second`.
 
+`requests_per_second`::
+
+The number of requests per second effectively executed during the update by query.
+
+`throttled_until_millis`::
+
+This field should always be equal to zero in a delete by query response. It only
+has meaning when using the <<docs-update-by-query-task-api, Task API>>, where it
+indicates the next time (in milliseconds since epoch) a throttled request will be
+executed again in order to conform to `requests_per_second`.
+
 `failures`::
 
 Array of all indexing failures. If this is non-empty then the request aborted