anchor.diff:  
   The advantage of this API is that it integrates with `wait_for_completion=false`
   to transparently return the status of completed tasks. If the task is completed
  -and `wait_for_completion=false` was set on it them it'll come back with a
  +and `wait_for_completion=false` was set on it, then it'll come back with a
   `results` or an `error` field. The cost of this feature is the document that
   `wait_for_completion=false` creates at `.tasks/task/${taskId}`. It is up to
   you to delete that document.
  
positive.code: // TESTRESPONSE[s/"took" : 147/"took" : "$body.took"/]
  
  `_update_by_query` gets a snapshot of the index when it starts and indexes what
  it finds using `internal` versioning. That means that you'll get a version
  conflict if the document changes between the time when the snapshot was taken
  and when the index request is processed. When the versions match the document
  is updated and the version number is incremented.
  
  NOTE: Since `internal` versioning does not support the value 0 as a valid
  
negative.code: before proceeding with the request. See <<index-wait-for-active-shards,here>>
  for details. `timeout` controls how long each write request waits for unavailable
  shards to become available. Both work exactly how they work in the
  <<docs-bulk,Bulk API>>. Because `_update_by_query` uses scroll search, you can also specify
  the `scroll` parameter to control how long it keeps the "search context" alive,
  e.g. `?scroll=10m`. By default it's 5 minutes.
  
  `requests_per_second` can be set to any positive decimal number (`1.4`, `6`,
  `1000`, etc.) and throttles the rate at which `_update_by_query` issues batches of
  index operations by padding each batch with a wait time. The throttling can be
  disabled by setting `requests_per_second` to `-1`.
  
  