Voting config exclusions APIs return \n response

[russcam]

Elasticsearch version (bin/elasticsearch --version): 7.8.0-SNAPSHOT

Plugins installed: []

JVM version (java -version): bundled JDK

OS version (uname -a if on a Unix-like system): Windows 10

Description of the problem including expected versus actual behavior:

The Voting Config Exclusions APIs (POST and DELETE) both return \n as the response with a content-type header of application/json and a content-length of 1. This response isn't valid JSON, and may require special handling in a language client, for example,

https://github.com/elastic/elasticsearch-net/pull/4738/files#diff-b2b266a90c4f392e9d643a396ef6a2d2R28-R38

Steps to reproduce:

1. Make a POST to /_cluster/voting_config_exclusions?node_names=node1%2Cnode2 or a DELETE request to /_cluster/voting_config_exclusions?wait_for_removal=true
2. Observe a response similar to

HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
content-length: 1

Possible solution(s)

• Return no response body

or

• Return an empty JSON object {}

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/REST API)

[DaveCTurner]

👍 The empty string (mod whitespace) is not valid JSON. I would prefer that we return an empty JSON object but either solution works for me, and the actual fix is rather simple. The bigger question is why the REST test suite didn't already notice this, which is why I've labelled this for the attention of the core/infra team. I investigated a bit myself but couldn't easily identify a good place to catch this.

[russcam]

Would another possible solution here be to return an acknowledged response i.e.

{ "acknowledged": true }

?

For the YAML tests, I think a match on $body for the expected response could be added to make the assertion. For example

elasticsearch/rest-api-spec/src/main/resources/rest-api-spec/test/cluster.voting_config_exclusions/10_basic.yml

Lines 14 to 17 in 3a15d84

	- do:
	cluster.post_voting_config_exclusions:
	node_ids: nodeId

could become

  - do:
      cluster.post_voting_config_exclusions:
        node_ids: nodeId

  - match: { $body: {} }

or if an acknowledged response

  - do:
      cluster.post_voting_config_exclusions:
        node_ids: nodeId

  - is_true: acknowledged

[DaveCTurner]

No, I don't think an acknowledged response is appropriate here. acknowledged: true means that every node in the cluster has applied the resulting cluster state, but that's irrelevant for voting config exclusions since these things are only used on the master.

For the tests, I'm looking for a way to assert more broadly that we never set Content-type: application/json and then return something that isn't valid JSON. We can obviously test these two cases easily enough but I think we should be able to make a stronger statement for all APIs

[DaveCTurner]

I'm looking for a way to assert more broadly that we never ... return something that isn't valid JSON

My attempts to do this timed out and slipped down my list. I don't think I will return to this task for the foreseeable future.