ElasticsearchClient.Indices.ExistsAsync throws exception if its the first API call.

[braveyp]

Elastic.Clients.Elasticsearch version: 8.15.1

Elasticsearch version: 8.15.0

.NET runtime version: 4.8

Operating system version: Windows11

Description of the problem including expected versus actual behavior:
If you instantiate a new ElasticsearchClient and make a call to Indices.ExistsAsync it fails with an error:

Elastic.Clients.Elasticsearch.UnsupportedProductException: The client noticed that the server is not a supported distribution of Elasticsearch or an unknown product.

If you precede the Indices.ExistsAsync call with a Cluster.HealthCheckAsync call the ExistsAsync call succeeds.

Steps to reproduce:

1. I created a brand new 8.15 install of elastic search and kibana having stopped my 7.16.x ES running on 9200.

2. This fails:

   public async Task FailingMethod()
   {
       var settings = new ElasticsearchClientSettings(new Uri("https://localhost:9205"));
       settings.Authentication(new BasicAuthentication("elastic", "<password>"));
       
       var client = new ElasticsearchClient(settings);
       var result2 = await client.Indices.ExistsAsync("test");
   }
   

3. This succeeds:

   public async Task SuccessfulMethod()
   {
       var settings = new ElasticsearchClientSettings(new Uri("https://localhost:9205"));
       settings.Authentication(new BasicAuthentication("elastic", "<password>"));
       
       var client = new ElasticsearchClient(settings);
       var result = await client.Cluster.HealthAsync();
       var result2 = await client.Indices.ExistsAsync("test");
   }
   

4. I've not tested with any other API call.

Expected behavior
I wouldn't expect to have to make another API call before the ExistsAsync works.

[flobernd]

Hi @braveyp, this looks like a regression in the 8.15.1 release. Please downgrade to 8.15.0 until a fix is available.

You could help me out here by attaching the JSON response that is returned in case of the ExistsAsync call (without calling any other endpoint first).

[braveyp]

Hi, sorry, I'm not sure how I'd do that - I don't get a response from the ExistsAsync call, I get an exception which doesn't include that information and I can't see a way to get logging from ElasticsearchClient. I'm not familiar with enabling logging on the elastic search server side so any pointers as to how to get the json response would be helpful.

[flobernd]

Hi @braveyp,

logging in the client can be enabled by adding these calls to your ElasticsearchClientSettings initialization code:

.DisableDirectStreaming()
.EnableDebugMode(cd =>
{
    Console.WriteLine(cd.DebugInformation);
})

Besides that, the full callstack of the exception would be useful for me 🙂

Btw.: Does your test index exists or not?

[braveyp]

I changed my code to:

        var settings = new ElasticsearchClientSettings(new Uri("https://localhost:9205"))
            .DisableDirectStreaming()
            .EnableDebugMode(cd =>
            {
                Console.WriteLine(cd.DebugInformation);
            })
            .Authentication(new BasicAuthentication("elastic", "<password>"));            
        var client = new ElasticsearchClient(settings);
        //var result = await client.Cluster.HealthAsync();
        var result2 = await client.Indices.ExistsAsync("test");

The debug information (though it doesn't include the json request and response data since the internal code seems to think DisableDirectStreaming isn't enabled despite it being explicitly enabled)

Successful (404) low level call on HEAD: /test?pretty=true&error_trace=true

Audit trail of this API call:

• [1] HealthyResponse: Node: https://localhost:9205/ Took: 00:00:00.2665359

Request:

<Request stream not captured or already read to completion by serializer. Set DisableDirectStreaming() on TransportConfiguration to force it to be set on the response.>

Response:

<Response stream not captured or already read to completion by serializer. Set DisableDirectStreaming() on TransportConfiguration to force it to be set on the response.>

TCP states:

TimeWait: 208
Established: 257
CloseWait: 3

ThreadPool statistics:

Worker:
Busy: 1
Free: 32766
Min: 24
Max: 32767
IOCP:
Busy: 0
Free: 1000
Min: 24
Max: 1000

The full stack trace:

at Elastic.Clients.Elasticsearch.ElasticsearchClient.<>c__DisplayClass861_03.<<DoRequestCoreAsync>g__SendRequestWithProductCheckCore|2>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Threading.Tasks.ValueTask1.get_Result()
at Elastic.Clients.Elasticsearch.ElasticsearchClient.<>c__DisplayClass861_03.<<DoRequestCoreAsync>g__SendRequestWithProductCheck|1>d.MoveNext() in /_/src/Elastic.Clients.Elasticsearch.Shared/Client/ElasticsearchClient.cs:line 193 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()
at Discovery.ElasticSearch.Client.Tests.BootstrapperTests.d__3.MoveNext() in C:\Source\DiscoveryTestBranch\Discovery.ElasticSearch.Client.Tests\BootstrapperTests.cs:line 78

Lastly, the index does not exist.

[flobernd]

@braveyp Thank you, this is helpful. The JSON is missing, because that specific response does not have a body. The debug output is still useful to e.g. see the status code (404).

One last question: How did you set up ES locally? Do you use our docker image or something like that? Did you set any specific config?

I'm asking because currently I'm not able to reproduce the issue with my 8.15 cloud instance.

[braveyp]

I just downloaded the latest es and kibana zip files, unzipped them into their own directories and then went through the semi-automated process to get kibana integrated with ES.

The only manual config change was that I had to shutdown my ES7 instance before setup, go through the integration process and then go back in and edit the configs to switch the port numbers to avoid conflicts with the ES7 versions. I've not restarted my ES7 instance since though so that shouldn't be the issue.

[braveyp]

Just to confirm the workaround, I created another test project to run the same test using Elastic.Clients.ElasticSearch 8.15.0 instead of 8.15.1 and the call succeeds.

The call also succeeds under 8.15.1 if the index actually exists.

[flobernd]

@braveyp Thanks for confirming this as well. It seems like the on-premise version does not send a required HTTP header, if the status code is not in the 200 range. I'm currently investigating this in detail and will create patch as soon as possible.

[flobernd]

@braveyp Should be fixed in 8.15.2. Please let me know, if this release resolves your issue.

[braveyp]

Thanks, that's resolved the issue.