Red cluster states and search query response codes

As described https://www.elastic.co/guide/en/elasticsearch/guide/current/_cluster_health.html when a cluster is in RED state search queries will return partial results, and indexing into that shard will return an exception.

However applications that may be searching an elasticsearch index that is in Red state will still get a status 200 in the http response and therefore may assume all is ok with the results returned.
The only way to know that the query did not successfully search all shards is by checking the _shards object or even worse calling the index health API prior to the search request.

"_shards": {
"total": 6,
"successful": 2,
"failed": 0
}

This is on Elasticsearch 1.7.5.

By default indexing requests are blocked when an index is in a red state, is there a way to do the same for search requests?
Alternatively provide a more appropriate response code for when partial results are returned from a RED index search, something akin to a HTTP "206 Partial Content".

Applications can then immediately decide whether to accept or reject the partial response without having to do inefficient pre search cluster/index state checks or post _shards object checks.

1 Like

It's an interesting point, I've raised it internally to see what other think, hopefully someone will comment in here too :slight_smile:

1 Like

This would be a misuse of HTTP 206 Partial Content; it is reserved for when the client sends a range request.

Also, conceptually it makes sense for indexing requests into a red index to be blocked. Index requests are handled on the primary shard first, and for a red index at least one primary shard for that index is unavailable.

In general, clients need to handle total/successful/failed responses as these sorts of responses are used in many places in the API to indicate total success/partial success/partial failure.

1 Like

Thanks for your response. Although I understand that clients can read and handle the total/successful/failed to detect the partial response, is it right that the onus is still on each and every client application to do this check rather than providing an option to flatly block the search centrally from within elasticsearch?
As far as I can see the requirement to check the _shards response is not mentioned in any documentation so at the very least documents referring to cluster health or search API's should mention the requirement to check the _shards object every time.

Documentation aside (which should be made far clearer), my request is can we get an index level option to block search requests when the index is in a Red state? Disabled by default so that everything still operates as today?

1 Like