Exception thrown trying to await requests tasks after multiple SearchAsync are called

[alessandro-gandolfi-ors]

Elastic.Clients.Elasticsearch version: 8.14.5

Elasticsearch version: 8.7.1

.NET runtime version: .NET 6

Operating system version: Windows 11

Description of the problem including expected versus actual behavior:
Calling multiple times SearchAsync and awaiting the responses after results in "Object reference not set to an instance of an object."

Steps to reproduce:

1. Initialize a SearchRequest
2. Call multiple times SearchAsync with the same SearchRequest and do NOT await the response, get the tasks instead
3. Await the tasks execution after

Expected behavior
The tasks should be awaited correctly, returning the results of the searches.

Provide DebugInformation (if relevant):
This wasn't an issue with NEST and ES7, it was reproduced after trying to upgrade to Elastic.Clients.Elasticsearch and ES8.
It was reproduced initially by running some tests that worked before the updates, that called some SearchAsync and CountAsync consecutively. The exception was sometimes thrown by the CountAsync too, so it's not limited to the SearchAsync method.

The next screenshot is a minimal test that reproduces the behaviour reported. The exception is thrown at the second or third awaited task.

[flobernd]

Hi @alessandro-gandolfi-ors,

I tried to reproduce this issue, but was not able to. This is the code I've used:

var q = new SearchRequest("person")
{
	Query = Query.MatchAll(new MatchAllQuery())
};

var t1 = client.SearchAsync<JsonObject>(q);
var t2 = client.SearchAsync<JsonObject>(q);
var t3 = client.SearchAsync<JsonObject>(q);

await Task.WhenAny(t1, t2, t3);

It would really help, if you could please post the complete call-stack of the NullReferenceException.

[alessandro-gandolfi-ors]

@flobernd I have censured some parts

This is the stacktrace:

System.NullReferenceException
  HResult=0x80004003
  Message=Object reference not set to an instance of an object.
  Source=Elastic.Clients.Elasticsearch
  StackTrace:
   at Elastic.Clients.Elasticsearch.ElasticsearchClient.<>c__DisplayClass28_0`3.<<DoRequestCoreAsync>g__SendRequest|0>d.MoveNext()
   at ***.Dao.DiagnosticService.<DiagnosticAsyncSearchRequests>d__3.MoveNext() in C:\Projects\***\Dao\DiagnosticService.cs:line 55

This is the callstack:

This is the callstack with external code enabled:

[flobernd]

Hi @alessandro-gandolfi-ors, could you please post a complete standalone reproducer project/solution for me that creates and index, seeds some data and afterwards runs the failing tests? I'm still not able to reproduce the problem.

[flobernd]

One thing to test before that maybe: What happens if you fire and await one initial request (e.g. InfoAsync()) using the same ElasticsearchClient instance, before executing the concurrent requests? If this works reliably, that would give me a strong hint in the right direction, I think.

[github-actions]

This issue is stale because it has been open 5 days with no activity. Remove stale label or comment or this will be closed in 2 days.

[alessandro-gandolfi-ors]

@flobernd sorry for not replying but right now I'm working on other projects, I will make the example project as soon as I begin again to work on the one regarding this package.

The initial problem was encountered by firing a search request that was not awaited and right after one that was awaited. The second one threw the exception:

[flobernd]

@alessandro-gandolfi-ors No worries about the delay. Before putting effort in creating such test/example project, could you please test this:

What happens if you fire and await one initial request (e.g. InfoAsync()) using the same ElasticsearchClient instance, before executing the concurrent requests?

So basically the other way around. The result of this test would be highly interesting.

[alessandro-gandolfi-ors]

@flobernd I tried to create a test as you said and even when firing more requests after the first await, the test always succeded and I never encountered the exception.

The first test without the first await continues to throw the exception most of the times I run it.