From b123408f681d102da93fdbec7e6af0345fb458bd Mon Sep 17 00:00:00 2001 From: David Turner Date: Tue, 19 Oct 2021 12:22:17 +0100 Subject: [PATCH] Add deprecation docs for cluster health HTTP code Documents the deprecation introduced in #78180 and adjusted in #79351. --- .../reference/migration/migrate_7_16.asciidoc | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/docs/reference/migration/migrate_7_16.asciidoc b/docs/reference/migration/migrate_7_16.asciidoc index 37469e3001107..e60a2a554c658 100644 --- a/docs/reference/migration/migrate_7_16.asciidoc +++ b/docs/reference/migration/migrate_7_16.asciidoc @@ -267,4 +267,30 @@ To avoid deprecation warnings, discontinue use of transient settings when modify your cluster settings through the `PUT _cluster/settings` REST API. When modifying cluster settings use only persistent settings. ==== + +[discrete] +[[breaking_716_cluster_deprecations]] +==== Cluster deprecations + +[[deprecate-cluster-health-408]] +.Distinguishing cluster health timeout status by HTTP response code is now deprecated. +[%collapsible] +==== +*Details* + +The <> API includes options for waiting for certain health +conditions to be satisfied. If the requested conditions are not satisfied +within a timeout then {es} will send back a normal response including the field +`"timed_out": true`. In earlier versions it would also use the HTTP response +code `408 Request timeout` if the request timed out, and `200 OK` otherwise. +The `408 Request timeout` response code is not appropriate for this situation +and its use is deprecated. Future versions will use the response code `200 OK` +for both cases. + +*Impact* + +Update your application to read the `"timed_out"` field of the response instead +of the HTTP response code to determine whether the request timed out or not. To +avoid deprecation warnings and opt into the future behaviour, include the query +parameter `?return_200_for_cluster_health_timeout` in your request. +==== + // end::notable-breaking-changes[]