First, the NEST client has changed its behavior. In 5.6, an empty response body would be treated as an invalid. In NEST 7.9, the result is treated as a zero count even though a correct response has the value in a JSON object. (NOTE: the test sets the response to null, and ElasticsearchInterceptingConnection changes that to an actual empty stream. This behavior was not changed when ElasticsearchInterceptingConnection was updated.)
Second, this test is nonsense. The HTTP status is set to 200, but the stream is set to null. A better "error response" test would return an HTTP status code other than 200. Also good test would use a partial response, simulating an interrupted connection - which is what GetCount_InvalidResponse does, that's the next test in the file. 🙂
Issue description
Following the update to Elasticsearch 7.9 and the NEST client, the
GetCount_ErrorResponsetest now fails.There are two things happening.
First, the NEST client has changed its behavior. In 5.6, an empty response body would be treated as an invalid. In NEST 7.9, the result is treated as a zero count even though a correct response has the value in a JSON object. (NOTE: the test sets the response to
null, andElasticsearchInterceptingConnectionchanges that to an actual empty stream. This behavior was not changed whenElasticsearchInterceptingConnectionwas updated.)Second, this test is nonsense. The HTTP status is set to 200, but the stream is set to null. A better "error response" test would return an HTTP status code other than 200. Also good test would use a partial response, simulating an interrupted connection - which is what
GetCount_InvalidResponsedoes, that's the next test in the file. 🙂Steps to reproduce the issue
What's the expected result?
What's the actual result?
Additional details / screenshot
Related Tickets